khera 98/06/12 11:07:11
Modified: . mod_perl_tuning.pod
Log:
Updated content for consistency with apache 1.3
Revision Changes Path
1.7 +28 -28 modperl/mod_perl_tuning.pod
Index: mod_perl_tuning.pod
===================================================================
RCS file: /home/cvs/modperl/mod_perl_tuning.pod,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- mod_perl_tuning.pod 1998/03/19 23:08:22 1.6
+++ mod_perl_tuning.pod 1998/06/12 18:07:09 1.7
@@ -109,10 +109,8 @@
# pull in things we will use in most requests so it is read and compiled
# exactly once
- use CGI::Base ();
- use CGI::BasePlus ();
- use CGI::Request ();
- use CGI::Form ();
+ use CGI ();
+ use CGI::Carp ();
use Mysql ();
1;
@@ -191,7 +189,7 @@
C<Apache::RegistryLoader> module so that the code for these programs
is shared by all HTTPD processes as well.
-B<NOTE>: When you pre-load modules in the startup script, you will
+B<NOTE>: When you pre-load modules in the startup script, you may
need to kill and restart HTTPD for changes to take effect. A simple
C<kill -HUP> or C<kill -USR1> will not reload that code unless you
have set the C<PerlFreshRestart> configuration parameter in
@@ -207,15 +205,18 @@
response time is increased even more.
The idea of the techniques outlined below is to offload the normal
-document delivery (such as HTML and GIF files) from the mod_perl
-HTTPD, and let it only handle the mod_perl requests. This way, your
-large mod_perl HTTPD processes are not tied up delivering simple
-content when a smaller process could perform the same job more
+document delivery (such as static HTML and GIF files) from the
+mod_perl HTTPD, and let it only handle the mod_perl requests. This
+way, your large mod_perl HTTPD processes are not tied up delivering
+simple content when a smaller process could perform the same job more
efficiently.
In the techniques below where there are two HTTPD configurations, the
same httpd executable can be used for both configurations; there is no
need to build HTTPD both with and without mod_perl compiled into it.
+With Apache 1.3 this can be done with the DSO configuration -- just
+configure one httpd invocation to dynamically load mod_perl and the
+other not to do so.
These approaches work best when most of the requests are for static
content rather than mod_perl programs. Log file analysis become a bit
@@ -313,15 +314,16 @@
=head2 SQUID ACCELERATOR
Another approach to reducing the number of large HTTPD processes on
-one machine is to use an accelerator such as Squid
-http://squid.nlanr.net/Squid/ between the clients and your large
-mod_perl HTTPD processes. The idea here is that squid will handle the
-static objects from its cache while the HTTPD processes will handle
-mostly just the mod_perl requests. This reduces the number of HTTPD
-processes and thus reduces the amount of memory used.
+one machine is to use an accelerator such as Squid (which can be found
+at http://squid.nlanr.net/Squid/ on the web) between the clients and
+your large mod_perl HTTPD processes. The idea here is that squid will
+handle the static objects from its cache while the HTTPD processes
+will handle mostly just the mod_perl requests once the cache is
+primed. This reduces the number of HTTPD processes and thus reduces
+the amount of memory used.
To set this up, just install the current version of Squid (at this
-writing, this is version 1.1.16) and use the RunAccel script to start
+writing, this is version 1.1.20) and use the RunAccel script to start
it. You will need to reconfigure your HTTPD to use an alternate port,
such as 8042, rather than its default port 80. To do this, just change
the F<httpd.conf> line C<Port> to match the port specified in
@@ -358,20 +360,18 @@
=head1 AUTHOR
-Vivek Khera. My email is I<MyFirstName@MyLastName.org>. I'd spell it
-out for you, but if this ends up on the net, I don't want some
-automatic mass-mail address collector to find me.
-
-This document is copyright 1997 by Vivek Khera.
-
-If you have contributions for this document, please send them to me or
-post them to the mailing list. Perl POD format is best, but plain
-text will do, too.
+This document is written by Vivek Khera. If you need to contact me,
+just send email to the mod_perl mailing list.
+This document is copyright E<copy> 1997-1998 by Vivek Khera.
+
+If you have contributions for this document, please post them to the
+mailing list. Perl POD format is best, but plain text will do, too.
+
If you need assistance, contact the mod_perl mailing list at
-modperl@LISTPROC.ITRIBE.NET first. There are lots of people there
+modperl@apache.org first. There are lots of people there
that can help. Also, check the web pages http://perl.apache.org/ and
http://www.apache.org/ for explanations of the configuration options.
-$Revision: 1.6 $
-$Date: 1998/03/19 23:08:22 $
+$Revision: 1.7 $
+$Date: 1998/06/12 18:07:09 $
Modified: . mod_perl_tuning.pod
Log:
Updated content for consistency with apache 1.3
Revision Changes Path
1.7 +28 -28 modperl/mod_perl_tuning.pod
Index: mod_perl_tuning.pod
===================================================================
RCS file: /home/cvs/modperl/mod_perl_tuning.pod,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- mod_perl_tuning.pod 1998/03/19 23:08:22 1.6
+++ mod_perl_tuning.pod 1998/06/12 18:07:09 1.7
@@ -109,10 +109,8 @@
# pull in things we will use in most requests so it is read and compiled
# exactly once
- use CGI::Base ();
- use CGI::BasePlus ();
- use CGI::Request ();
- use CGI::Form ();
+ use CGI ();
+ use CGI::Carp ();
use Mysql ();
1;
@@ -191,7 +189,7 @@
C<Apache::RegistryLoader> module so that the code for these programs
is shared by all HTTPD processes as well.
-B<NOTE>: When you pre-load modules in the startup script, you will
+B<NOTE>: When you pre-load modules in the startup script, you may
need to kill and restart HTTPD for changes to take effect. A simple
C<kill -HUP> or C<kill -USR1> will not reload that code unless you
have set the C<PerlFreshRestart> configuration parameter in
@@ -207,15 +205,18 @@
response time is increased even more.
The idea of the techniques outlined below is to offload the normal
-document delivery (such as HTML and GIF files) from the mod_perl
-HTTPD, and let it only handle the mod_perl requests. This way, your
-large mod_perl HTTPD processes are not tied up delivering simple
-content when a smaller process could perform the same job more
+document delivery (such as static HTML and GIF files) from the
+mod_perl HTTPD, and let it only handle the mod_perl requests. This
+way, your large mod_perl HTTPD processes are not tied up delivering
+simple content when a smaller process could perform the same job more
efficiently.
In the techniques below where there are two HTTPD configurations, the
same httpd executable can be used for both configurations; there is no
need to build HTTPD both with and without mod_perl compiled into it.
+With Apache 1.3 this can be done with the DSO configuration -- just
+configure one httpd invocation to dynamically load mod_perl and the
+other not to do so.
These approaches work best when most of the requests are for static
content rather than mod_perl programs. Log file analysis become a bit
@@ -313,15 +314,16 @@
=head2 SQUID ACCELERATOR
Another approach to reducing the number of large HTTPD processes on
-one machine is to use an accelerator such as Squid
-http://squid.nlanr.net/Squid/ between the clients and your large
-mod_perl HTTPD processes. The idea here is that squid will handle the
-static objects from its cache while the HTTPD processes will handle
-mostly just the mod_perl requests. This reduces the number of HTTPD
-processes and thus reduces the amount of memory used.
+one machine is to use an accelerator such as Squid (which can be found
+at http://squid.nlanr.net/Squid/ on the web) between the clients and
+your large mod_perl HTTPD processes. The idea here is that squid will
+handle the static objects from its cache while the HTTPD processes
+will handle mostly just the mod_perl requests once the cache is
+primed. This reduces the number of HTTPD processes and thus reduces
+the amount of memory used.
To set this up, just install the current version of Squid (at this
-writing, this is version 1.1.16) and use the RunAccel script to start
+writing, this is version 1.1.20) and use the RunAccel script to start
it. You will need to reconfigure your HTTPD to use an alternate port,
such as 8042, rather than its default port 80. To do this, just change
the F<httpd.conf> line C<Port> to match the port specified in
@@ -358,20 +360,18 @@
=head1 AUTHOR
-Vivek Khera. My email is I<MyFirstName@MyLastName.org>. I'd spell it
-out for you, but if this ends up on the net, I don't want some
-automatic mass-mail address collector to find me.
-
-This document is copyright 1997 by Vivek Khera.
-
-If you have contributions for this document, please send them to me or
-post them to the mailing list. Perl POD format is best, but plain
-text will do, too.
+This document is written by Vivek Khera. If you need to contact me,
+just send email to the mod_perl mailing list.
+This document is copyright E<copy> 1997-1998 by Vivek Khera.
+
+If you have contributions for this document, please post them to the
+mailing list. Perl POD format is best, but plain text will do, too.
+
If you need assistance, contact the mod_perl mailing list at
-modperl@LISTPROC.ITRIBE.NET first. There are lots of people there
+modperl@apache.org first. There are lots of people there
that can help. Also, check the web pages http://perl.apache.org/ and
http://www.apache.org/ for explanations of the configuration options.
-$Revision: 1.6 $
-$Date: 1998/03/19 23:08:22 $
+$Revision: 1.7 $
+$Date: 1998/06/12 18:07:09 $