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: [EMAIL PROTECTED]
