On Fri, 19 Jan 2001, Sam Horrocks wrote:
> > You know, I had brief look through some of the SpeedyCGI code yesterday,
> > and I think the MRU process selection might be a bit of a red herring.
> > I think the real reason Speedy won the memory test is the way it spawns
> > processes.
>
> Please take a look at that code again. There's no smoke and mirrors,
> no red-herrings.
I didn't mean that MRU isn't really happening, just that it isn't the
reason why Speedy is running fewer interpeters.
> Also, I don't look at the benchmarks as "winning" - I
> am not trying to start a mod_perl vs speedy battle here.
Okay, but let's not be so polite about things that we don't acknowledge
when someone is onto a better way of doing things. Stealing good ideas
from other projects is a time-honored open source tradition.
> Speedy does not check on every request to see if there are enough
> backends running. In most cases, the only thing the frontend does is
> grab an idle backend from the lifo. Only if there are none available
> does it start to worry about how many are running, etc.
Sorry, I had a lot of the details about what Speedy is doing wrong.
However, it still sounds like it has a more efficient approach than
Apache in terms of managing process spawning.
> You're correct that speedy does try not to overshoot, but mainly
> because there's no point in overshooting - it just wastes swap space.
> But that's not the heart of the mechanism. There truly is a LIFO
> involved. Please read that code again, or run some tests. Speedy
> could overshoot by far, and the worst that would happen is that you
> would get a lot of idle backends sitting in virtual memory, which the
> kernel would page out, and then at some point they'll time out and die.
When you spawn a new process it starts out in real memory, doesn't
it? Spawning too many could use up all the physical RAM and send a box
into swap, at least until it managed to page out the idle
processes. That's what I think happened to mod_perl in this test.
> If you start lots of those on a script that says 'print "$$\n"', then
> run the frontend on the same script, you will still see the same pid
> over and over. This is the LIFO in action, reusing the same process
> over and over.
Right, but I don't think that explains why fewer processes are running.
Suppose you start 10 processes, and then send in one request at a time,
and that request takes one time slice to complete. If MRU works
perfectly, you'll get process 1 over and over again handling the requests.
LRU will use process 1, then 2, then 3, etc. But both of them have 9
processes idle and one in use at any given time. The 9 idle ones should
either be killed off, or ideally never have been spawned in the first
place. I think Speedy does a better job of preventing unnecessary process
spawning.
One alternative theory is that keeping the same process busy instead of
rotating through all 10 means that the OS can page out the other 9 and
thus use less physical RAM.
Anyway, I feel like we've been putting you on the spot, and I don't want
you to feel obligated to respond personally to all the messages on this
thread. I'm only still talking about it because it's interesting and I've
learned a couple of things about Linux and Apache from it. If I get the
chance this weekend, I'll try some tests of my own.
- Perrin
