>>> esper at sherohman.org 05/29/01 07:58PM >>>
>>On Tue, May 29, 2001 at 05:49:20PM -0500, Troy Johnson wrote:
>> <WARNING: This may be wrong for any number of reasons ;-)>
>Just one error, relatively minor in scope, but fairly major in effect.

I thank you for pointing it out!

>> Mod_perl makes the Perl interpreter part of the httpd itself, so that
>> startup costs are negated and memory usage is less (compared to the
>> full blown interpreter), but it also beefs up _every_ httpd
>This is half true.  Yes, there's a full copy of the perl interpreter (and any
>perl modules loaded in with PerlRequire or PerlModule, plus mod_perl itself
>and any other apache modules that are configured) preloaded into every httpd.
>However, Linux (like most, if not all, other modern OSes) is smart enough to
>use copy-on-write semantics.  Basically, what this means is that when a child
>process is spawned, all of its pointers reference the parent's memory space
>and the referenced data doesn't get copied until one process or the other
>tries to modify it.

I hadn't considered what Linux does to make things better, but I should have.
When viewing my 'httpd's in 'top', is the memory shown there the actual amount
of memory each daemon is using, or how much it would use if it wrote to the
inherited memory space?

>Since the actual executable code isn't allowed to be modified at runtime,
>this means that all the httpds are sharing the same perl interpreter.

Yes.

>By comparison, using traditional CGI, each child spawns its own interpreter.
>Since it's not inherited from the parent, sharing the memory doesn't come as
>easily and any parts that aren't in .so libraries are likely to be duplicated
>in each child.

Would it be advantageous to encapsulate most of the Perl interpreter in an
.so library so that traditional CGIs could share that memory? I seem to
remember something about that sort of thing being available (but not
recommended yet) when compiling Perl 5.6.

>So you've got it backwards:  Because mod_perl can share data more effectively
>between httpd processes, it can easily end up taking less average memory
>(and will take up no more peak memory) than traditional CGI scripting.

Thank you once again!

Troy