stas 2003/03/11 22:37:07
Modified: src/docs/2.0/user config.cfg
src/docs/2.0/user/compat compat.pod
Added: src/docs/2.0/user/performance prevent.pod
Log:
- issues with server_root_relative and pools
- start the performance group
- start the preventing chapter
- add a section on pool's life length
Revision Changes Path
1.20 +5 -0 modperl-docs/src/docs/2.0/user/config.cfg
Index: config.cfg
===================================================================
RCS file: /home/cvs/modperl-docs/src/docs/2.0/user/config.cfg,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- config.cfg 15 Dec 2002 17:36:38 -0000 1.19
+++ config.cfg 12 Mar 2003 06:37:07 -0000 1.20
@@ -38,6 +38,11 @@
handlers/general.pod
)],
+ group => 'Performance',
+ chapters => [qw(
+ performance/prevent.pod
+ )],
+
group => 'Troubleshooting',
chapters => [ qw(
troubleshooting/troubleshooting.pod
1.1 modperl-docs/src/docs/2.0/user/performance/prevent.pod
Index: prevent.pod
===================================================================
=head1 NAME
Preventive Measures for Performance Enhancement
=head1 Description
This chapter explains what should or should not be done in order to
keep the performance high
=head1 Memory Leakage
L<Memory leakage in 1.0 docs|docs::1.0::guide::performance/Memory_leakage>.
=head2 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
(C<$r-E<gt>pool>) are destroyed at the end of each request. Connection
pools (C<$c-E<gt>pool>) are destroyed when the connection is
closed. Server pools C<$s-E<gt>pool>) and the global pools (accessible
in the server startup phases, like C<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 $conf_dir = Apache::server_root_relative($s->pool, 'conf');
when you can call:
my $conf_dir = Apache::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.
=head1 Maintainers
Maintainer is the person(s) you should contact with updates,
corrections and patches.
=over
=item *
Stas Bekman E<lt>stas (at) stason.orgE<gt>
=back
=head1 Authors
=over
=item *
Stas Bekman E<lt>stas (at) stason.orgE<gt>
=back
Only the major authors are listed above. For contributors see the
Changes file.
=cut
1.57 +28 -1 modperl-docs/src/docs/2.0/user/compat/compat.pod
Index: compat.pod
===================================================================
RCS file: /home/cvs/modperl-docs/src/docs/2.0/user/compat/compat.pod,v
retrieving revision 1.56
retrieving revision 1.57
diff -u -r1.56 -r1.57
--- compat.pod 11 Mar 2003 03:11:01 -0000 1.56
+++ compat.pod 12 Mar 2003 06:37:07 -0000 1.57
@@ -357,6 +357,17 @@
C<L<Apache::ServerUtil|docs::2.0::api::Apache::ServerUtil>>
manpage.
+=head2 C<Apache-E<gt>untaint>
+
+C<Apache-E<gt>untaint> has moved to
+C<L<Apache::ServerUtil|docs::2.0::api::ModPerl::Util>> and now is a
+function, rather a class method. It'll will untaint all its
+arguments. You shouldn't be using this function unless you know what
+you are doing. Refer to the I<perlsec> manpage for more information.
+
+C<L<Apache::compat|docs::2.0::api::Apache::compat>> provides the
+backward compatible with mod_perl 1.0 implementation.
+
=head2 C<Apache-E<gt>get_handlers>
Avalable via C<Apache::compat>. To get handlers for the server level,
@@ -655,9 +666,25 @@
=head2 C<$r-E<gt>server_root_relative>
-C<Apache::server_root_relative> is a function in 2.0.
+C<Apache::server_root_relative> is a function in 2.0 and its first
+argument is the I<pool> object. For example:
+ # during request
my $conf_dir = Apache::server_root_relative($r->pool, 'conf');
+ # during startup
+ my $conf_dir = Apache::server_root_relative($s->pool, 'conf');
+
+The old way:
+
+ my $conf_dir = Apache::server_root_relative('Apache', 'conf');
+
+will work as well, but you shouldn't use it, because it'll internally
+use a global pool, which is a bit slower, but the worst drawback is
+that every time you use this way the allocated from this pool memory
+won't be cleaned up, till the server quits so there will be a memory
+leak. When you are inside a request and use C<$r-E<gt>pool>, this pool
+is freed at the end of each request.
+
See the L<Apache::ServerUtil> manpage.
