This is a discussion on Re: mod_perl survey results - modperl ; 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 ...
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).
Need professional mod_perl support?
Just hire me: firstname.lastname@example.org