On Thu, 27 Apr 2000, Stas Bekman wrote:
> On Tue, 25 Apr 2000, Doug MacEachern wrote:
>
> > On Fri, 21 Apr 2000, Greg Cope wrote:
> >
> > > Does this mean that we {will|may} be able to use the interpreter pool to
> > > set up X Perl interpreters (say 20 to service dynamic handlers) with Z
> > > apache (say 60 to handle static + dynamic content - assuming the dynamic
> > > content is passed to the Perl interpreters) children, and hence have
> > > significant memory savings as we can avoid (in some cases) the light / heavy
> > > httpd model ?
> >
> > yes, exactly.
>
> 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.
