NAME
Preventive Measures for Performance Enhancement
Description
This chapter explains what should or should not be done in order to keep the performance high
Memory Leakage
Proper Memory Pools Usage
Several mod_perl 2.0 APIs are using Apache memory pools for memory management. Mainly because the underlying C API requires that. So every time Apache needs to allocate memory it allocates it using the pool object that is passed as an argument. Apache doesn't frees allocated memory, this happens automatically when a pool ends its life.
Different pools have different life lengths. Request pools ($r->pool) are destroyed at the end of each request. Connection pools ($c->pool) are destroyed when the connection is closed. Server pools $s->pool) and the global pools (accessible in the server startup phases, like PerlOpenLogsHandler handlers) are destroyed only when the server exits.
Therefore always use the pool of the shortest possible life if you can. Never use server pools during request, when you can use a request pool. For example inside an HTTP handler, don't call:
my $dir = Apache2::ServerUtil::server_root_relative($s->process->pool, 'conf');when you should call:
my $dir = Apache2::ServerUtil::server_root_relative($r->pool, 'conf');Of course on special occasions, you may want to have something allocated off the server pool if you want the allocated memory to survive through several subsequent requests or connections. But this is normally doesn't apply to the core mod_perl 2.0, but rather for 3rd party extensions.
Maintainers
Maintainer is the person(s) you should contact with updates, corrections and patches.
Stas Bekman <stas (at) stason.org>
Authors
Stas Bekman <stas (at) stason.org>
Only the major authors are listed above. For contributors see the Changes file.