I could never find out what's the difference between nginx and
mongrel. All my searches say "nginx is a HTTP server ..." and "Mongrel
is a fast HTTP library and server for Ruby....". For me they both mean
"...HTTP server...".
I kept up with this question for some time till I came across this
santence from the guys at Friend for Sale:
Both are indeed HTTP server, but their focus is different. Mongrel is a fast HTTP server aimed mostly at Ruby-based applications. On top of that, it’s easily extensible with Ruby code. However, it’s not very good at serving static files, i.e. it’s slower than Apache and nginx. Also, Rails is single threaded, meaning that during the course of a request (calling a controller method until the actual rendering) the mongrel is locked.
To work around the above mentioned disadvantages of Mongrel and Rails, the preferred setup in a production app is to put either Apache or nginx as the main webserver and if a request for a non-static Rails page is received, to pass this to a number of underlying mongrels, let the mongrel hand back the rendered page to Apache/nginx and serve that page, together with static files such as images/stylesheets/… It might seem a bit daunting and complex at first, but once you actually implement it, it’s extremely powerful and stable (I have several apps that have been running for months to years on a server without a single restart).
It boils down to this, let Apache/nginx do what it’s best at, let the mongrel cluster do what it’s best at, everybody is happy.
Choosing nginx over Apache is mostly based on memory considerations. Apache is quite a hefty webserver, especially if all you actually do is serve some static files with it and balance the rest over a bunch of mongrels. Nginx is very lightweight and performant and can do the same job just as good as Apache. But if you’re familiar with Apache, don’t want to get the grips with nginx configuration and have lots of memory on your server, you can still go for Apache. On a basic VPS, nginx is a more suitable approach.
Thanks for the detailed explanation Peter. Makes me better informed.
So when people say they have x number of mongrels running, do they
mean their server (nginx?) is serving x number of requests
simultaneously?
Yes, and that means real concurrent dynamically generated page requests (cached pages will be served directly).
Keep in mind that a normal http request takes far less than a second in normal circumstances (that’s what you should aim for), so you can serve quite a few requests/sec on one mongrel, adding mongrels just increases that number. Even if all mongrels are in use, the user’s request will just be queued until a mongrel is available again. Starting too many mongrels in a cluster can possibly slow down your website instead of speed it up.
The nice thing about Rails is that you can scale as the need arises and by then you will be very comfortable with the rest of your setup.
All I’m saying is: don’t rent a tanker if you need to transport one cup of water.
And who will manage the memcached? nginx?
Since memcached caches model and session data, it’s Rails that handles this in all but very few cases. And memcached is something you’ll need when you really need to scale big.
So when people say they have x number of mongrels running, do they
mean their server (nginx?) is serving x number of requests
simultaneously?
If the request is for a static resource, say a static image, CSS, static HTMLpage, etc, then nginx can handle these itself. On top of that, it can pass back to the mongrel servers the dynamic resource requests. Nginx can pass back as many dynamic requests as mongrel servers simultaneously, on top of that it can server many more static resource requests, IIRC.