How 7 Mongrels Handled a 550k Pageview Digging(shanti.railsblog.com)
shanti.railsblog.com
How 7 Mongrels Handled a 550k Pageview Digging
http://shanti.railsblog.com/how-7-mongrels-handled-a-550k-pageview-digging
18 comments
I am wondering why X mongrels are commonly used with Rails, is it just how mongrel is designed and dispatched that you need to establish X amount and it does not change with the load?
Being completely ignorant of mongrel, what is the benefit of having 7 mongrels running instead of 1? Does it not just do the job of dispatching the child processes to handle requests, so one would handle things just as effectively? I suppose what I am asking is, with one box why would you have more than one dispatcher?
Being completely ignorant of mongrel, what is the benefit of having 7 mongrels running instead of 1? Does it not just do the job of dispatching the child processes to handle requests, so one would handle things just as effectively? I suppose what I am asking is, with one box why would you have more than one dispatcher?
one mongrel handles one request. if you request takes one second to complete. you get one request/sec. 7 mongrels => 7 req/sec.
100req/sec * 7 mongrels => 700 req/sec total. and other simple math.
they aren't spawned automatically. you setup a number and distribute to them. there are ways of getting them to spawn automatically, but it isn't inherent to mongrel itself.
100req/sec * 7 mongrels => 700 req/sec total. and other simple math.
they aren't spawned automatically. you setup a number and distribute to them. there are ways of getting them to spawn automatically, but it isn't inherent to mongrel itself.
Oh, I see, thanks.
So I now ask, why have not spawn them automatically?
That's a really good question, eh? :)
It seems to me the webserver would then need to support that (dynamic allocation of additional target mongrels).
The way it works currently is you put Apache2 / Lighty / nginx / etc in front, working as a proxy, which has a list of host/port pairs which it forwards on the request to.
The proxying end of things would have to be smart enough to tell mongrel to startup more processes, and begin forwarding more requests to those.
It seems to me the webserver would then need to support that (dynamic allocation of additional target mongrels).
The way it works currently is you put Apache2 / Lighty / nginx / etc in front, working as a proxy, which has a list of host/port pairs which it forwards on the request to.
The proxying end of things would have to be smart enough to tell mongrel to startup more processes, and begin forwarding more requests to those.
Whereas, with something like Rivet or Websh (or PHP for that matter, even if I don't like the language), it's good old tried and true Apache taking care of dynamically allocating new servers as needs be... fancy that!
I love Rails, but those guys are too anxious to throw the Apache baby out with the PHP bathwater.
I love Rails, but those guys are too anxious to throw the Apache baby out with the PHP bathwater.
I agree, being forced to know ahead of time how many mongrels you'll need is sub-optimal.
At the same time, it's trivial to switch this number if you've not hit your server resource limits yet. (i.e. when coming under a digg load)
Once server limits are reached (in Apache or nginx/mongrel/rails), the point is moot - you'll have to instantiate new servers at your co-lo / hosting company by hand anyway.
All that said, nginx is a fantastic web & proxy server. It blows Apache out of the water in terms of memory usage, etc.
At the same time, it's trivial to switch this number if you've not hit your server resource limits yet. (i.e. when coming under a digg load)
Once server limits are reached (in Apache or nginx/mongrel/rails), the point is moot - you'll have to instantiate new servers at your co-lo / hosting company by hand anyway.
All that said, nginx is a fantastic web & proxy server. It blows Apache out of the water in terms of memory usage, etc.
nginx - isn't it just another in a long line of select-based web servers that "blow Apache out of the water" when it comes to serving static resources? boa was what I set up to serve static files at Linuxcare back in ... 1999? Or is nginx different somehow? That's fine as far as it goes, but the tricky part lies in serving up the dynamic stuff.
It's not select based, it is event based, utilizing the relatively new support for event-driven IO in the Linux and FreeBSD kernels (kqueue/epoll).
Ok, so it's a slightly different architecture, but it's still really an evolution of the single-process select-based server. To do anything "application like" - running code in ruby, php, python - you apparently (correct me if I'm wrong, because I'm just going from what I found after 5 minutes on the site) have to farm things out to FCGI, so you're back to the Apache model of separate processes - noting of course that unlike some people erroneously think, apache's processes each have a select loop, so it's not just forking processes for every connection!
My point is that the application processes are where things are tricky. Even 'big slow apache' can saturate fast connections with static content. The real trick is to get the most out of your dynamic code without under utilizing your resources (by launching only one mongrel instance, for example), or running things into the ground by letting your apps try and grab too much memory.
My point is that the application processes are where things are tricky. Even 'big slow apache' can saturate fast connections with static content. The real trick is to get the most out of your dynamic code without under utilizing your resources (by launching only one mongrel instance, for example), or running things into the ground by letting your apps try and grab too much memory.
Nginx is both incredibly fast at serving static files and pretty useful all around for reverse proxies and whatnot (not to mention being easier to configure/maintain than apache). I use it at work and it has been fantastic.
i just noticed replies.
mongrel doesn't do it for the same reason tar doesn't support encryption (pgp does!).
mongrel is designed to serve requests, not balance requests or spawn itself. sure it could, but it doesn't have to. it is just as easy to have another project spawn more mongrels. That way if I want to to write software just for looking at my servers and making more mongrels, i can, very easily. Otherwise i have to look in mongrel's code.
mongrel doesn't do it for the same reason tar doesn't support encryption (pgp does!).
mongrel is designed to serve requests, not balance requests or spawn itself. sure it could, but it doesn't have to. it is just as easy to have another project spawn more mongrels. That way if I want to to write software just for looking at my servers and making more mongrels, i can, very easily. Otherwise i have to look in mongrel's code.
I really like the approach of having X number of processes started automatically. You can get really fine-grained in your scaling strategy, and can balance multiple projects on the same server much better than you could with Apache.
If you really want the "automatic blah blah blah" approach, you can always use fcgi with Apache. Many people do (including 37signals).
If you really want the "automatic blah blah blah" approach, you can always use fcgi with Apache. Many people do (including 37signals).
I don't remember where I got the following snippet from so if someone knows, please point it out so that I can give them credit.
How many mongrels?
Here's a simple formula to follow:
A. Take the (average or median) request time, in seconds. Say, 0.250 seconds (250ms)
B. How many requests do you want to handle at peak? (e.g. 10,000 a minute, 166 a second)
C. Multiply A x B : 0.250 * 166 = 41.5
So you need about 40 mongrels to handle the load. At about 60MB per listener, that's 2.4GB of RAM, plus a bit of room for leakiness and swapping. Ezra at Engine Yard suggests "about 10 dogs per CPU core", which means that if we have a 4-core opteron box with 3GB of RAM, then this is possible on one box.
Your mileage will vary, which means, if the box is lagging, remove a few mongrels.
How many mongrels?
Here's a simple formula to follow:
A. Take the (average or median) request time, in seconds. Say, 0.250 seconds (250ms)
B. How many requests do you want to handle at peak? (e.g. 10,000 a minute, 166 a second)
C. Multiply A x B : 0.250 * 166 = 41.5
So you need about 40 mongrels to handle the load. At about 60MB per listener, that's 2.4GB of RAM, plus a bit of room for leakiness and swapping. Ezra at Engine Yard suggests "about 10 dogs per CPU core", which means that if we have a 4-core opteron box with 3GB of RAM, then this is possible on one box.
Your mileage will vary, which means, if the box is lagging, remove a few mongrels.
i'm not much of a rails head but I did enjoy that article and it makes me happy that we're using nginx on http://Skribit.com
Skribit looks sweet - is it RoR powered or what?
Are you in YCombinator?
Are you in YCombinator?
> As the title of this article suggests, only 7 mongrels were required to sustain the level of traffic. (this number was already set to seven before the digging, and didn't have to be increased)
Having to pick arbitrary numbers beforehand is a bad way of scaling. Apache with fcgid launches new processes as they're needed. It may not scale due to other problems, but "pick a number and pray" strikes me as a dubious idea.