On Monday 04 June 2007 18:43, Jani M. wrote: > For comparison, a server with one gig of memory can run roughly 600 > preforked workers with some spare memory left for disk caching. Any more > than this, and performance drops as disk access increases.
These figures match my observations. It also means that you are not using big
content generators in the response phase like Catalyst.
> With threaded processes, I can easily have the same machine run 5x the
> number of threads, with some 400-500 perl interpreters available. This
> is very helpful when you need to be able to serve a large amount of
> concurrent slow(ish) clients.
>
> Obviously the configuration I have uses 'PerlInterpScope handler' to
> maximize the benefit from the interpreters-to-threads ratio.
This is by now the only usable configuration with the worker MPM and it's
really useful. Especially if you allow keepalive requests which is a dont
with prefork MPM. It may have benefits even with "PerlInterpScope request".
Did you know this little trick?
In PostReadRequest or so:
$r->pnotes->{xp}=$r->pool->new;
$r->push_handlers(PerlFixupHandler=>sub {delete $_[0]->pnotes->{xp}; 0});
It binds the interpreter to your request for the whole time from
PostReadRequest to Fixup and hence enables $r->pnotes. It may be useful when
passing complex Perl structures or anonymous coderefs. But be watch out not
to call $r->discard_request_body or so in one of these phases.
But be aware this is very hackish land.
Did you know that you can even share data between Perl interpreters by
using "threads" and "threads::shared"?
The main problem with the memory consumption of perl interpreters with worker
MPM is that they are not shared by copy-on-write. There is one main
interpeter per process that is cloned in ChildInit (or later). I think
copy-on-write can be used for multiple interpreters if they are cloned
already in the parent process before it forks. I am thinking of a patch to
implement this. But it would mean to abandon growing and shrinking of the
interpreter pool and the limit of requests per interpreter. But in the end I
think it would be more reasonable than it is now.
Does this make sense?
Torsten
pgpCMMj6hSAht.pgp
Description: PGP signature
