[CDBI] Class-DBI on mod_perl2 (Apache2 threaded)

Ryan Tate lists at ryantate.com
Fri Nov 11 06:50:56 GMT 2005

On 11/8/05, Perrin Harkins <perrin at elem.com> wrote:
> Threads take more memory.  Nothing is shared with perl threads, and you
> lose the copy-on-write sharing.

I may well be misunderstanding, but I thought mod_perl2 threaded
(worker MPM) maintained a pool of perl interpreters that are shared
among threads, and that the number of perl interpreters can be
significantly less than the number of threads. From the docs:

"Even though memory sharing is not applicable inside the same process,
mod_perl gets a significant memory saving, because Perl interpreters
have a shared opcode tree. Similar to the preforked model, all the
code that was loaded at the server startup, before Perl interpreters
are cloned, will be shared. But there is a significant difference
between the two. In the prefork case, the normal memory sharing
applies: if a single byte of the memory page gets unshared, the whole
page is unshared, meaning that with time less and less memory is
shared. In the threaded mpm case, the opcode tree is shared and this
doesn't change as the code runs.

"Moreover, since Perl Interpreter pools are used, and the FIFO model
is used, if the pool contains three Perl interpreters, but only one is
used at any given time, only that interpreter will be ever used,
making the other two interpreters consuming very little memory. So if
with prefork MPM, you'd think twice before loading mod_perl if all you
need is trans handler, with threaded mpm you can do that without
paying the price of the significanly increased memory demands. You can
have 256 light Apache threads serving static requests, and let's say
three Perl interpreters running quick trans handlers, or even heavy
but infrequest dynamic requests, when needed."

--from: http://perl.apache.org/docs/2.0/user/performance/mpm.html#Memory_Requirements_in_Threaded_MPM

More information about the ClassDBI mailing list