perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Foertsch <torsten.foert...@gmx.net>
Subject Re: mod_perl survey results
Date Mon, 10 Nov 2008 17:37:55 GMT
On Mon 10 Nov 2008, Steven Siebert wrote:
> More memory but potentially faster, correct?  Since we don't have to
> spawn as many processes to accommodate a load?

Perl is a real memory hog. Byte-compiled code can become quite big. 
Multiply that with the number of perl interpreters running and you'll 
get huge numbers. With the prefork MPM we use the "load all modules you 
need at startup" mantra. This way the operating system comes to rescue 
with copy-on-write. The byte-compiled code is almost read-only after it 
is compiled. If it is compiled by the perl interpreter in the parent 
apache all that memory becomes shared memory.

With a threaded MPM the situation is different. Here at startup we have 
one perl interpreter that loads all the modules. Then AFTER the child 
is forked it creates as many as configured additional interpreters. 
Each of those is a copy of the master interpreter. But now all the 
memory that holds the byte-compiled code is allocated again for each 
interpreter and almost nothing is shared by copy-on-write. So the 
creation of a new perl interpreter is really expensive.

Although there is one sane usage of modperl with a threaded MPM, I 
believe. If your only modperl usage is to configure the request at 
runtime, do authentication etc you need the interpreter only for a 
small part of the request cycle. So you can configure say 3 
interpreters to handle 250 or so threads. But for that to become usable 
we need a better modperl and perhaps better MPMs (event based).

Torsten

--
Need professional mod_perl support?
Just hire me: torsten.foertsch@gmx.net

Mime
View raw message