> This costs memory, and all the more since many perl modules are not 
> thread-safe, so if you use them in your code, at this moment the only safe 
> way to do it is to use the Apache httpd prefork model. This means that each 
> Apache httpd child process has its own copy of the perl interpreter, which 
> means that the memory used by this embedded perl interpreter has to be 
> counted n times (as many times as there are Apache httpd child processes 
> running at any one time).

This isn’t quite true - if you load modules before the process forks then they 
can cleverly share the same parts of memory. It is useful to be able to 
"pre-load" core functionality which is used across all functions {this is the 
case in Linux anyway}. It also speeds up child process generation as the 
modules are already in memory and converted to byte code.

One of the great advantages of mod_perl is Apache2::SizeLimit which can blow 
away large child process - and then if needed create new ones. This is not the 
case with some of the FCGI solutions as the individual processes can grow if 
there is a memory leak or a request that retrieves a large amount of content 
(even if not served), but perl can't give the memory back. So FCGI processes 
only get bigger and bigger and eventually blow up memory (or hit swap first) 





-- 
 The Wellcome Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.

Reply via email to