On Thu, 21 Dec 2000, Ken Williams wrote:
> So in a sense, I think you're both correct. If "concurrency" means
> the number of requests that can be handled at once, both systems are
> necessarily (and trivially) equivalent. This isn't a very useful
> measurement, though; a more useful one is how many children (or
> perhaps how much memory) will be necessary to handle a given number of
> incoming requests per second, and with this metric the two systems
> could perform differently.
Yes, well put. And that actually brings me back around to my original
hypothesis, which is that once you reach the maximum number of
interprerters that can be run on the box before swapping, it no longer
makes a difference if you're using LRU or MRU. That's because all
interpreters are busy all the time, and the RAM for lexicals has already
been allocated in all of them. At that point, it's a question of which
system can fit more interpreters in RAM at once, and I still think
mod_perl would come out on top there because of the shared memory. Of
course most people don't run their servers at full throttle, and at less
than total saturation I would expect speedycgi to use less RAM and
possibly be faster.
So I guess I'm saying exactly the opposite of the original assertion:
mod_perl is more scalable if you define "scalable" as maximum requests per
second on a given machine, but speedycgi uses fewer resources at less than
peak loads which would make it more attractive for ISPs and other people
who use their servers for multiple tasks.
This is all hypothetical and I don't have time to experiment with it until
after the holidays, but I think the logic is correct.
- Perrin
