perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Ludwig <...@as-guides.com>
Subject Re: article about mod_perlite
Date Mon, 26 Jan 2009 21:15:18 GMT
Perrin Harkins schrieb:
> On Mon, Jan 26, 2009 at 2:26 PM, Michael Ludwig <mlu@as-guides.com>
> wrote:
>> I think this is technically incorrect in that it does not match the
>> Apache/LibPHP execution model (which is what I think they're trying
>> to emulate), where the Apache/LibPHP process does not exit after
>> serving only a single request.
>
> Well, is your goal to be exactly like PHP or is it to provide a fast
> environment for non-persistent perl execution?  Perl doesn't have the
> same kind of reset switch for the interpreter, so creating a new one
> each time is necessary.

I may be wrong but I used to think that PerlRun provides just that, a
non-persistent execution environment, just like LibPHP. Memory consumed
by the interpreter is not deallocated in either case. (Unless, of
course, I'm wrong.)

> Setting MaxRequestsPerChild to 1 causes apache to prefork a new
> process with a new interpreter for each request.  This should be
> faster than attempting to actually create a new interpreter, since
> all it has to do is fork the parent process and forking is very
> efficient on Linux and BSD.

Yes, relatively light-footed processes on these platforms. But if
forking was so efficient, why offer PerlRun?

> PerlRun is effective in many situations but it will never be as
> effective as forking a fresh process/interpreter.

That may or may not be true depending on what effect you want to
achieve. As for efficiency, I used to think that PerlRun had an edge
over forking in that respect. But well, I may be wrong.

>> PHP can leak memory, too. MaxRequestsPerChild is important, as it is
>> with Perl. Setting it to 1 in either case means throwing the baby out
>> with the bath water.
>
> I disagree.  In fact this was a common recommendation for use with
> PerlRun in the old days when people had scripts that were just too
> dirty to get running in a persistent environment.

Too dirty for more than one request on PerlRun? Never seen anything as
dirty as that.

But wait, I once came upon a homegrown "framework" that implemented an
HTTP redirect by printing the header, flushing the buffer and then
calling exit(), which terminated the Apache process. That was really
dirty. The icing on the cake was that it didn't close the database
handle, and I suspected it of being the culprit for the connection
leakage we were seeing. But lacking in-depth knowledge, I never got to
the ground of it.

Note the doc for PerlRun says: "This module is meant for 'Dirty' CGI
Perl scripts [...]". Note it says "Dirty" with a capital D.

Best,

Michael Ludwig

Mime
View raw message