

How 7 Mongrels Handled a 550k Pageview Digging - sbraford
http://shanti.railsblog.com/how-7-mongrels-handled-a-550k-pageview-digging

======
davidw
Here's what's annoying about Mongrel, summed up:

> 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.

~~~
mrtron
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?

~~~
socmoth
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.

~~~
mrtron
Oh, I see, thanks. So I now ask, why have not spawn them automatically?

~~~
sbraford
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.

~~~
davidw
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.

~~~
sbraford
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.

~~~
davidw
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.

~~~
altano
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).

~~~
davidw
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.

------
luccastera
_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.

------
PStamatiou
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>

~~~
sbraford
Skribit looks sweet - is it RoR powered or what?

Are you in YCombinator?

------
wmf
One app server and one DB server counts as "scaling" now?

~~~
carpal
No, and the author never said it was.

