=head1 NAME

Performance Considerations Under Different MPMs

=head1 Description

This chapter discusses how to choose the right MPM to use (on
platforms that have such a choice), and how to get the best
performance out of it.

Certain kind of applications may show a better performance when
running under one mpm, but not the other. Results also may vary from
platform to platform.

CPAN module developers have to strive making their modules function
correctly regardless the mpm they are being deployed under. However
they may choose to indentify what MPM the code is running under and do
better decisions better on this information, as long as it doesn't
break the functionality for other platforms. For examples if a
developer provides thread-unsafe code, the module will work correctly
under the prefork mpm, but may malfunction under threaded mpms.

=head1 Memory Requirements

Since the very beginning mod_perl users have enjoyed the tremendous
speed boost mod_perl was providing, but there is no free lunch --
mod_perl has quite big memory requirements, since it has to store the
compiled code in the memory to avoid the code loading and
recompilation overhead for each request.

=head2 Memory Requirements in Prefork MPM

For those familiar with mod_perl 1.0, mod_perl 2.0 has not much new to
offer. We still rely on L<shared
memory|docs::1.0::guide::performance/Sharing_Memory>, try to 
L<preload as many things as possible at the server
startup|docs::1.0::guide::performance/Preloading_Perl_Modules_at_Server_Startup>
and L<limit the amount of used
memory|docs::1.0::guide::performance/Preventing_Your_Processes_from_Growing>
using specially designed for that purpose tools.

The new thing is that the core API has been spread across multiply
modules, which can be loaded only when needed (this of course works
only when mod_perl is built as DSO). This allows us to save some
memory. However the savings are not big, since all these modules are
writen in C, making them into the text segments of the memory, which
is perfectly shared. The savings are more significant at the startup
speed, since the startup time, when DSO modules are loaded, is growing
almost quadratically as the number of loaded DSO modules grows
(because of symbol relocations).

=head2 Memory Requirements in Threaded MPM

The threaded MPM is a totally new beast for mod_perl users. If you run
several processes, the same memory sharing techniques apply, but
usually you want to run as few processes as possible and to have as
many threads as possible. Remember that mod_perl 2.0 allows you to
have just a few Perl interpreters in the process which otherwise runs
multiple threads. So using more threads doesn't mean using
significantly more memory, if the maximum number of available Perl
interpreters is limited.

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.

It's not clear yet, how one will be able to control the amount of
running Perl interepreters, based on the memory consumption, because
it's not possible to get the memory usage information per
thread. However we are thinking about running a garbage collection
thread which will cleanup Perl interpreters and occasionaly kill off
the unused ones to free up used memory.

=head1 Work with DataBases

=head2 Work with DataBases under Prefork MPM

C<Apache::DBI> works as with mod_perl 1.0, to share database
connections.

=head2 Work with DataBases under Threaded MPM

The current C<Apache::DBI> should be usable under threaded mpm, though
it doesn't share connections across threads. Each Perl interpreter has
its own cache, just like in the prefork mpm.

C<DBI::Pool> is a work in progress, which should bring the sharing of
database connections across threads of the same process. Watch the
mod_perl and dbi-dev lists for updates on this work. Once C<DBI::Pool>
is completed it'll either replace C<Apache::DBI> or will be used by
it.



=head1 Maintainers

Maintainer is the person(s) you should contact with updates,
corrections and patches.

=over

=item *

Stas Bekman [http://stason.org/]

=back

=head1 Authors

=over

=item *

Stas Bekman [http://stason.org/]

=back

Only the major authors are listed above. For contributors see the
Changes file.

=cut
