So my father runs a rather small business. I'm going to set him up with a website using RefineryCMS (that's a ror-based cms).. He will probably get less than 500 hits a month. Do I really need to set up mongrel cluster for this as about every tutorial on the web suggests?
Does anyone some good reading material for setting up a simple, small scale RoR-production environment? I want to move away from apache and try nginx or lighttpd as the server. What would be YOUR preferred setup for a site that will get between 100 and 500 hits a month?
Thanks !
Simplest answer is Passenger. If you know Apache, use it, otherwise use Nginx. It's a piece of cake to setup, and manages the processes for you. It's pretty much like setting up a PHP site. Here's a link
You could host such a setup on heroku.com free stack and not have to worry about setting up your own server.
We even have a tutorial: http://tutorials.refinerycms.org/tutorials/how-to-install-refinery-on-heroku
Even easier to run: unicorn. But probably needs nginx too to handle slow connections (over the internet).
Related
According to: https://github.com/iphoting/heroku-buildpack-php-tyler/issues/21
Cloudflare needs raw in-bound port 2408 into the dyno and it is still not possible with the new dyno networking model.
Anyone found a way? Any ideas?
You can always install and run Railgun on a separate machine (such as a cheap VPS), and then enable that Railgun on your site. You'd want to make sure that VPS with the Railgun on it is located close to wherever it is Heroku would host your origin for the least amount of latency from the VPS to your origin.
So with this setup it'd go:
client <--> Railgun on a VPS <--> Heroku origin
It won't be the perfect solution, and instead of getting 100% of the performance you'd like see something like 85% performance benefit.
It's not ideal, but it's at least an option. I have this kind of setup on several Heroku apps/sites I use. I have a VPS on Ramnode providing Railgun for these Heroku apps/sites:
https://request.canhazip.com/
https://ip.canhazip.com/
https://httpbin.canhazip.com/
p.s. I work at CloudFlare.
I read from some books that Phusion Passenger is the answer to easy Ruby on Rails deployment. But my friend said that first there was Apache + bunch of Mongrels, and then lighttpd, and then nginx, and now Passenger, and it seems endless...
he also said he uses dreamhost which uses Passenger, and sometimes he sees his request not being processed.
So I wonder if Passenger is the final answer to RoR deployment? do you use it and used the "ab" command to test if the site is doing quite well?
short answer: yes.
long answer: yeeeeeeeeeeeeeeesssssssssssssssss.
In all seriousness, Phusion Passenger and Ruby Enterprise Edition have taken out pretty much all of the pain of moving a Rails app into production. Previous approaches, including running a suite of Mongrels, required lots of setup surrounding starting, stopping, and recycling listener processes that Passenger handles transparently, or via simple Apache (or nginx) configuration options. And REE's complementary garbage collector means that forking off a new listener uses MUCH less memory, and is faster to boot (in Passenger's "smart" spawning mode).
Edit: #srboisvert makes a very good point; Passenger isn't the final answer to RoR deployment, but for now it's my favorite by far. One day, after a lot of hard engineering problems are solved, mainstream Ruby will probably move from hosting RoR using a multi-process model to a single-process model, which would make management even easier than with Passenger.
It's the best solution so far. I started deploying with FCGI and it was a pain. Then came mongrel and it was better. Then came mod_rails and it was WAY better.
Also a lot of large cool application are migrating to mod_rails including some by 37signals, so you know that's good.
I'll just end with a quote from DHH:
The one-piece solution with Phusion
Passenger
Once you've completed the incredibly
simple installation, you get an Apache
that acts as both web server, load
balancer, application server and
process watcher. You simply drop in
your application and touch
tmp/restart.txt when you want to
bounce it and bam, you're up and
running.
But somehow the message of Passenger
has been a little slow to sink in.
There's already a ton of big sites
running off it. Including Shopify,
MTV, Geni, Yammer, and we'll be moving
over first Ta-da List shortly, then
hopefully the rest of the 37signals
suite quickly thereafter.
So while there are still reasons to
run your own custom multi-tier setup
of manually configured pieces, just
like there are people shying away from
mod_php for their particulars, I think
we've finally settled on a default
answer. Something that doesn't require
you to really think about the first
deployment of your Rails application.
Something that just works out of the
box. Even if that box is a shared
host!
In conclusion, Rails is no longer hard
to deploy. Phusion Passenger has made
it ridiculously easy.
(via)
Yes, it is the easiest, fastest and most efficient solution.
After a lot of problems with gems like soap4r etc. had been resolved in recent releases, Passenger is the answer to deployment questions now.
We're running Apache/mod_rails in a balanced environment with HAProxy in front of 2 servers. It's much more reliable than our previous setup using Mongrel/Aapache.
It's very easy to take control over
the amount of Passenger processes running in Apache
the amount of Passenger processes running per application
and all that without the pain of tweaking a number of config files like mod_proxy, Apache.
setting up a virtual host and adding 3 lines to your Apache config is basically enough to get it running
Matt
Final Answer? Nothing is ever the final answer.
I'd say Passenger is the current answer though.
Yes. I've been running Nginx/Passenger in front of Apache for whatever still needs PHP since they released 2.2.0 a few weeks back. Especially with Ruby Enterprise Edition, it approaches what I would call "perfect".
I guess that now people will stick to mod_rails for many years. The module is really good. Configuration is dead simple. It will be hard to replace it with some better solution. Similar to mod_php. The only key component which is missing: Windows port.
In some situations (enterprise, etc) the JVM can also be a good option.
I have recently installed Nginx + Thin on my deployment server, but i am not sure how this will perform in last requests & responses situation. lets say 1000/req per sec.
so the speed on thin is good with 10-100 req /per sec
I wanted to know on higher volumes of data being processed on the request/response cluster.
Guide me on this :-)
Multiple thin processes and nginx are capable of providing lots of speed, depending on what your application is doing. So, the problem will be your application code, the speed of your application server, and your database server.
Scaling Rails has been recently covered in depth by the Scaling Rails Screencasts. I recommend you start there. My 5 step program to scaling Rails would be:
First step is to have the tools to look at what is slow in your application. Do not spend time optimizing everything in your application when you don't know what the problem is.
The easiest way to be able to handle lots of requests/second is with page caching.
If you can't do that, cache everything possible (fragment caching, use memcached to cache data, etc), to speed up your application.
After that, optimize your application as best as possible, make SQL queries fast, index everything, etc.
If you still need more speed, throw more hardware at the problem. Get a big, powerful database server, a bunch of app servers, and proxy your requests across them. You can start here, too, but it will only delay the optimization process.
If you have a single server I think that the main key is, apart from everything already mentioned, is don't skimp on the specs of it. Trying to get too much to run on too little is just a recipe for disaster.
It is also a good idea to get monit or God monitoring your thin instances, I started out with God, but it leaked memory pretty bad on Ruby 1.8.6 so I stop using it in favour of monit. Monit is written in C I believe and has a tiny memory footprint so I'd recommend that one.
If all that seems like a bit much to keep nginx and thin playing nicely you may want to look into an all in one solution like Passenger or LiteSpeed. I have very little experience with these so can offer no substancial advice for them.
I'm running into a problem in a Rails application.
After some hours, the application seems to start hanging, and I wasn't able to find where the problem was. There was nothing relevant in the log files, but when I tried to get the url from a browser nothing happened (like mongrel accept the request but wasn't able to respond).
What do you think I can test to understand where the problem is?
I might get voted down for dodging the question, but I recently moved from nginx + mongrel to mod_rails and have been really impressed. Moving to a much simpler setup will undoubtedly save me headaches in the future.
It was a really easy transition, I'd highly recommend it.
Are you sure the problem is caused by Mongrel? Have you tried running your application under WEBrick?
There are a few things you can check, but since you say there's nothing in the logs to indicate error, it sounds like you might be running into a bug when using the log rotation feature of the Logger class. It causes mongrel to lock up. Instead of relying on Logger to rotate your logs, consider using logrotate or some other external log rotation service.
Does this happen at a set number of hours/days every time? How much RAM do you have?
I had this same problem. The couple options I had narrowed it down to were MySQL adapter related. I was running on Red Hat Enterprise Linux 4 (or 5) and the app would hang after a given amount of idle time.
One suggested solution was to compile native MySQL bindings, I had been using the pure Ruby one.
The other was to set the timeout on the MySQL adapter higher than what the connection would idle out on. (I don't have the specific configuration recorded, but as I recall it was in environment.rb and it was some class variable in the mysql adapter.)
I don't recall if either of those solutions fixed it, we moved to Ubuntu shortly after that and hadn't had a problem since.
Check the Mongrel FAQ:
http://mongrel.rubyforge.org/wiki/FAQ
From my experience, mongrel hangs when:
the log file got too big (hundreds of megabytes in size). you have to setup log rotation.
the MySQL driver times out
you have to change the timeout settings of your MySQL driver by adding this to your environment.rb:
ActiveRecord::Base.verification_timeout = 14400
(this is further explained in the deployment section of the FAQ)
Unfortunately, Rails (and thereby Mongrel) using up too much memory over time and crashing is a known problem (50K+ Google entries for "Ruby, rails, crashing, memory"). The current ruby interpreter has the property that it sometimes simply fails entirely to give memory back to the system - it may reuse the memory it has but it won't give it up.
There are numerous schemes for monitoring, killing and restarting Mongrel instances in a production environment - for example: (choosing at random) rails monitor . Until the problem is fixed more decisively, one of these may be your best bet.
We have experienced this same issue. First off, install the mongrel_proctitle gem
http://github.com/rtomayko/mongrel_proctitle/tree/master
This gem/plugin will allow you to view the mongrel processes via "ps" and you can see if a Mongrel is hung. An issue we have seen with Mongrel is that it will happily accept connections and enqueue them, then wedge itself. This plugin will help you see when a Mongrel has been wedged but then you must use another monitoring app to actually restart a a wedged Mongrel, something like Monit or God
You might also want to consider putting a more balanced reverse proxy in front of your Mongrels, something HAproxy, instead of nginx, Apache or Lighttpd. With a setting of "maxconn 1" in HAproxy you can assure that the queue is being maintained by HAproxy versus Mongrel. The other reverse proxies (nginx, Apache, Lighttpd) only do round-robin which means that they can load up your Mongrel queue, inadvertently.
My personal choice is God as it is much more flexible.
tl;dr Install this gem plugin and keep an eye on your Mongrels. Try Apache+Phusion Passenger.
Should i stay out of rails if a client has a cheap hosting service with a provider that do not support mod_rails? Will rails + fast.cgi provide a good experience for a user or should I choose, in this scenario, php + my-favorite-framework as platform ?
Regards,
Victor
Fastcgi should be fine. Though it has been generally recommended to host rails apps on a platform that you own. There are some pretty affordable virtual private servers out there that let you do this.
I have three clients on inexpensive hosting plans using FastCGI and have not run into any issues due to FastCGI itself. These are all low traffic sites where Mongrel was not necessary.
Will rails + fast.cgi provide a good experience for a user
It all depends on what you're trying to do. If you're going to build a site where users will uploading and playing video then no FastCGI is not a good choice.
or should I choose, in this scenario, php + my-favorite-framework as platform
You always choose the right tool for the job. Without any details on what you are trying to build I'm not sure anyone here will be able to tell you how to build it.
My experience on low end hosts was really really bad. Constantly having my mongrel instances die inexplicably. Since switching to a slice I have had zero problems running it on my own.
I would tend to avoid FastCGI. I haven't used it myself but I've read enough horror stories about it to never want to.
If the hosting company is going to be completely responsible for managing the server instance and you can trust them to be the ones who will make sure the app is always up and running, then maybe it would work. I doubt this is the case though, and if you don't own the servers I think you'll run into a lot of problems troubleshooting the all the weird bugs FastCGI will inevitably throw at you.
Don't worry about mod_rails: it's new and Rails sites were running fine before it turned up. It's nice to have, I'm sure, but not a necessity.
By the time you're looking to get rails to scale to volumes that really need mod_rails, the site should be worth putting into an environment that runs it.