Gunther Birznieks wrote:
> Sam just posted this to the speedycgi list just now.
[...]
> >The underlying problem in mod_perl is that apache likes to spread out
> >web requests to as many httpd's, and therefore as many mod_perl interpreters,
> >as possible using an LRU selection processes for picking httpd's.
Hmmm... this doesn't sound right. I've never looked at the code in
Apache that does this selection, but I was under the impression that the
choice of which process would handle each request was an OS dependent
thing, based on some sort of mutex.
Take a look at this: http://httpd.apache.org/docs/misc/perf-tuning.html
Doesn't that appear to be saying that whichever process gets into the
mutex first will get the new request? In my experience running
development servers on Linux it always seemed as if the the requests
would continue going to the same process until a request came in when
that process was already busy.
As I understand it, the implementation of "wake-one" scheduling in the
2.4 Linux kernel may affect this as well. It may then be possible to
skip the mutex and use unserialized accept for single socket servers,
which will definitely hand process selection over to the kernel.
> >The problem is that at a high concurrency level, mod_perl is using lots
> >and lots of different perl-interpreters to handle the requests, each
> >with its own un-shared memory. It's doing this due to its LRU design.
> >But with SpeedyCGI's MRU design, only a few speedy_backends are being used
> >because as much as possible it tries to use the same interpreter over and
> >over and not spread out the requests to lots of different interpreters.
> >Mod_perl is using lots of perl-interpreters, while speedycgi is only using
> >a few. mod_perl is requiring that lots of interpreters be in memory in
> >order to handle the requests, wherase speedy only requires a small number
> >of interpreters to be in memory.
This test - building up unshared memory in each process - is somewhat
suspect since in most setups I've seen, there is a very significant
amount of memory being shared between mod_perl processes. Regardless,
the explanation here doesn't make sense to me. If we assume that each
approach is equally fast (as Sam seems to say earlier in his message)
then it should take an equal number of speedycgi and mod_perl processes
to handle the same concurrency.
That leads me to believe that what's really happening here is that
Apache is pre-forking a bit over-zealously in response to a sudden surge
of traffic from ab, and thus has extra unused processes sitting around
waiting, while speedycgi is avoiding this situation by waiting for
someone to try and use the processes before forking them (i.e. no
pre-forking). The speedycgi way causes a brief delay while new
processes fork, but doesn't waste memory. Does this sound like a
plausible explanation to folks?
This is probably all a moot point on a server with a properly set
MaxClients and Apache::SizeLimit that will not go into swap. I would
expect mod_perl to have the advantage when all processes are
fully-utilized because of the shared memory. It would be cool if
speedycgi could somehow use a parent process model and get the shared
memory benefits too. Speedy seems like it might be more attractive to
ISPs, and it would be nice to increase interoperability between the two
projects.
- Perrin
