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

Reply via email to