On Nov 8, 2007, at 12:31 AM, Octavian Rasnita wrote:

> Hi,
> Can you please tell me when the server forks?

As indicated here:

Basically, the server starts then parses the configuration script
(all pre mod_perl).
The fist phase we have access to with mod_perl is the
phase. Then comes the PerlPostConfigHandler, the last phase before
the child
processes get spawned. Then you have the PerlChildInitHandler phase run
at the beginning of every child spawned by the server, run only once
per child
process. These and the final PerlChildExitHandler phase (run once
the child is exiting)
are all server level phases.

> What should I do to load some classes before the server forks?

If I'm not mistaken the earliest you can affect a change in the
server is in any
startup.pl type files. They will be run during the configuration
parse. The first
handler phase PerlOpenLogsHandler is run after this. It was
suggested you wait until
the PerlPostConfigHandler phase if you want to load or construct
stuff on
the server level (parent server). It will have the structures you
included in
your startup.pl file available, so tends to be more useful for
running scripts.

> What should I do if I want to load the classes after the server forks?

There are many phases after the fork, the most commonly used is the
PerlResponseHandler phase:


ANy of the phases mentioned on that page will be post fork.

Hope that helps...

> Thank you for clarifications.
> Octavian
> ----- Original Message ----- From: "Perrin Harkins"
> To: "Boysenberry Payne"
> Cc: "modperl List"
> Sent: Thursday, November 08, 2007 1:04 AM
> Subject: Re: mod_perl2 and Apache::SharedMem
>> On Nov 7, 2007 5:50 PM, Boysenberry Payne
>> wrote:
>>> If I created some of my static hashes and objects during the
>>> PerlPostConfigHandler phase
>>> and added them to either the configuration or log pools

>> You're missing the big picture. Adding perl objects to a shared
>> memory pool doesn't prevent them also needing to be in perl's own
>> allocated memory pool. All shared memory schemes with perl result in
>> MORE memory being used, because every process that accesses these
>> structures needs its own copy in its own process in addition to the
>> shared one. The shared memory one is a serialized perl structure,
>> created with something like Storable and perl has to turn it back
>> into
>> a normal perl variable, in non-shared memory, in order to use it.
>> You can't use less memory by sharing your perl data with user-level
>> shared memory techniques. Only copy-on-write can help with that.
>>> I have classes that create singleton objects with lots of static
>>> parts. Should I build these "constructs"
>>> on server post config so they're already built in the child
>>> processes
>>> as shared memory rather than
>>> building them in each child, increasing the non-shared memory use?

>> Build them before the server forks if you use prefork.
>>> Would it allow me to reduce what I have set for
>>> $Apache2::SizeLimit::MAX_UNSHARED_SIZE?

>> You shouldn't be using that at all unless you have Linux::Smaps
>> installed, but if you do, loading things before forking should
>> improve
>> the amount of copy-on-write sharing.
>> - Perrin