I was referring to script initialization (responding to that first request)
and not the httpd daemon startup. Really, the only "startup" that should be
slower is when the whole httpd service is restarted (such as at server
startup) since it would have to preload all modules for all standby daemons.
<<<<<
Sorry for the misunderstanding - startup to me only refers to server
startup. In my mod_perl setup all code is loaded at server startup, there is
no additional code initialisation once the server is running.
Additionally if you preload your modules and code, then it is initialised
only once in the parent apache process. When the child processes are forked
to handle the requests, they are an exact copy of the parent so inherit all
the perl code that was pre-loaded, saving additional load time.
I would expect (or hope -- I don't really know) that any individual httpd
daemons that get re-initialized later on automatically (when
MaxRequestsPerChild is reached) would be done after the previous request so
they are ready for the next request.
<<<<<
When MaxRequestsPerChild is reached, the child process shuts down at the end
of a request cycle. returning any distinct resources to the OS. The parent
then forks a new child process in exactly the same way as it did after
startup. The same process is followed depending your spare server
configuration settings.
Something else I will do for my low-usage but "massive" scripts (those that
have large memory structures and take several seconds to execute) is to
place these in a non-mod_perl directory so I can be assured their memory
usage goes away at the end of the response.
<<<<<
There's no reason not to run these under mod_perl too - any memory allocated
by perl will be re-used.
If you're really concerned and would rather the child process quits and
frees additional memory to the OS, then call $r->child_terminate in any of
your handlers, and the child process will automatically quit at the end of
the request (same as if it had hit it's MaxRequests limit)
Carl
