: > > But you will be not able to tune the two types of the threads to have
: > > different Apache parameters (MaxRequests and others) so I'm not sure
you
: > > will get rid of the dual setup, unless these will be taken care of by
: > > mod_perl.
: >
: >well, there is a PerlInterpMaxRequests parameter in 1.99_01-dev, which
: >knocks off the Perl clone after x number of requests. in addition, the
: >pool of interpreters are pulled and putback from the head of the list, so
: >you are getting re-used allocations (e.g. padlists aka lexicals). that
: >is, say you configured PerlInterpStart to 10, but average no more than 5
: >concurrent requests. you have 5 clones with allocated padlists, and 5
: >which are much smaller (but ready for conncurrent requests > 5). this is
: >unlike 1.3 where you have 10 children, chances are high each of them will
: >endup will allocated padlists, as there's no control over which child
: >handles a request.
: >
: >i'm not saying 2.0 will rid the need for a dual setup, but the Perl side
: >is looking a whole lot smaller (er, less fat) at this point.
If using the threaded model can we not configure say:
10 apache children (fixed)
X number of threads
Y PerlInterpStart
This would (if my understanding is correct) result in a request arriving and
being :
- either be dealt with by a normal apache thread if not a mod_perl
handler - i.e {html|gif|png|jpeg}
- or a by a light apache thread that calls a perlInterpreter from the pool
to handle the mod_perl handler....
Combine with a garbage collector thread this would be excellent as it would
seriously reduce memory consumption (one of mod_perl's present weaknesses)
and result in IMHO the best architecture between all the JSP/Servlets/PHP
combos.
Just thinking aloud - so I could have got this completely wrong!
Greg Cope
