How 7 Mongrels Handled a 550k Pageview Digging
shanti.railsblog.com
shanti.railsblog.com
> 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.
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?
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.
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.
I love Rails, but those guys are too anxious to throw the Apache baby out with the PHP bathwater.
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.
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.
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.
If you really want the "automatic blah blah blah" approach, you can always use fcgi with Apache. Many people do (including 37signals).
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.
Are you in YCombinator?