You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl-cvs@perl.apache.org by kh...@hyperreal.org on 1998/12/07 17:21:25 UTC
cvs commit: modperl-site/tuning mod_perl_tuning.html
khera 98/12/07 08:21:25
Modified: tuning mod_perl_tuning.html
Log:
Updated from version in current mod_perl CVS tree.
Revision Changes Path
1.3 +178 -135 modperl-site/tuning/mod_perl_tuning.html
Index: mod_perl_tuning.html
===================================================================
RCS file: /home/cvs/modperl-site/tuning/mod_perl_tuning.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- mod_perl_tuning.html 1998/06/12 19:03:20 1.2
+++ mod_perl_tuning.html 1998/12/07 16:21:23 1.3
@@ -50,11 +50,12 @@
<H1><A NAME="DESCRIPTION">DESCRIPTION
</A></H1>
-Described here are examples and hints on how to configure a mod_perl enabled Apache server, concentrating on tips for configuration for high-speed performance. The primary way to achieve maximal performance is to reduce the resources consumed by the mod_perl enabled
-<FONT SIZE=-1>HTTPD</FONT> processes.
+Described here are examples and hints on how to configure a mod_perl
+enabled Apache server, concentrating on tips for configuration for
+high-speed performance. The primary way to achieve maximal performance is
+to reduce the resources consumed by the mod_perl enabled HTTPD processes.
-
<P>
This document assumes familiarity with Apache configuration directives some
@@ -66,11 +67,11 @@
<P>
-
-These performance tuning hints are collected from my experiences in setting up and running servers for handling large promotional sites, such as The Weather Channel's ``Blimp Site-ings'' game, the
-<FONT SIZE=-1>MSIE</FONT> 4.0 ``Subscribe to Win'' game, and the
-<FONT SIZE=-1>MSN</FONT> Million Dollar Madness game.
+These performance tuning hints are collected from my experiences in setting
+up and running servers for handling large promotional sites, such as The
+Weather Channel's ``Blimp Site-ings'' game, the MSIE 4.0 ``Subscribe to
+Win'' game, and the MSN Million Dollar Madness game.
<P>
@@ -81,23 +82,17 @@
</A></H1>
The basic configuration for mod_perl is as follows. In the
-<EM>httpd.conf</EM> file,
-<FONT SIZE=-1>I</FONT> add configuration parameters to make the
-<CODE>http://www.domain.com/programs</CODE>
-<FONT SIZE=-1>URL</FONT> be the base location for all mod_perl programs.
-Thus, access to
+<EM>httpd.conf</EM> file, I add configuration parameters to make the
+<CODE>http://www.domain.com/programs</CODE> URL be the base location for all mod_perl programs. Thus, access to
<CODE>http://www.domain.com/programs/printenv</CODE> will run the printenv script, as we'll see below. Also, any *.perl file
will be interpreted as a mod_perl program just as if it were in the
-programs directory, and *.rperl will be mod_perl, but <EM>without</EM> any
-<FONT SIZE=-1>HTTP</FONT> headers automatically sent; you must do this
-explicitly. If you don't want these last two, just leave it out of your
-configuration.
+programs directory, and *.rperl will be mod_perl, but <EM>without</EM> any HTTP headers automatically sent; you must do this explicitly. If you
+don't want these last two, just leave it out of your configuration.
<P>
-In the configuration files,
-<FONT SIZE=-1>I</FONT> use <EM>/var/www</EM> as the <CODE>ServerRoot</CODE>
+In the configuration files, I use <EM>/var/www</EM> as the <CODE>ServerRoot</CODE>
directory, and <EM>/var/www/docs</EM> as the <CODE>DocumentRoot</CODE>. You will need to change it to match your particular setup. The network
address below in the access to perl-status should also be changed to match
yours.
@@ -157,9 +152,7 @@
<P>
-Now, you'll notice that
-<FONT SIZE=-1>I</FONT> use a <CODE>Perlrequire</CODE> directive to load in the file <EM>startup.perl</EM>. In that file,
-<FONT SIZE=-1>I</FONT> include all of the <CODE>use</CODE>
+Now, you'll notice that I use a <CODE>PerlRequire</CODE> directive to load in the file <EM>startup.perl</EM>. In that file, I include all of the <CODE>use</CODE>
statements that occur in any of my mod_perl programs (either from the
programs directory, or the *.perl files). Here is an example:
@@ -180,13 +173,14 @@
# make sure we are in a sane environment.
$ENV{GATEWAY_INTERFACE} =~ /^CGI-Perl/ or die "GATEWAY_INTERFACE not Perl!";
- use Apache::Registry; # for things in the "/programs" URL
+ use Apache::Registry (); # for things in the "/programs" URL
# pull in things we will use in most requests so it is read and compiled
# exactly once
- use CGI ();
+ use CGI (); CGI->compile(':all');
use CGI::Carp ();
- use Mysql ();
+ use DBI ();
+ use DBD::mysql ();
</PRE>
<P>
@@ -197,11 +191,10 @@
<P>
What this does is pull in all of the code used by the programs (but does
-not <CODE>import</CODE> any of the module methods) into the main
-<FONT SIZE=-1>HTTPD</FONT> process, which then creates the child processes
-with the code already in place. You can also put any new modules you like
-into the
-<EM>/var/www/perllib</EM> directory and simpley <CODE>use</CODE> them in your programs. There is no need to put <CODE>use lib "/var/www/perllib";</CODE> in all of your programs. You do, however, still need to <CODE>use</CODE> the modules in your programs. Perl is smart enough to know it doesn't need
+not <CODE>import</CODE> any of the module methods) into the main HTTPD process, which then creates
+the child processes with the code already in place. You can also put any
+new modules you like into the
+<EM>/var/www/perllib</EM> directory and simply <CODE>use</CODE> them in your programs. There is no need to put <CODE>use lib "/var/www/perllib";</CODE> in all of your programs. You do, however, still need to <CODE>use</CODE> the modules in your programs. Perl is smart enough to know it doesn't need
to recompile the code, but it does need to <CODE>import</CODE> the module methods into your program's name space.
@@ -252,9 +245,8 @@
<P>
-When you run this, check the value of the
-<FONT SIZE=-1>GATEWAY_INTERFACE</FONT> variable to see that you are indeed
-running mod_perl.
+When you run this, check the value of the GATEWAY_INTERFACE variable to see
+that you are indeed running mod_perl.
<P>
@@ -264,51 +256,48 @@
<H1><A NAME="REDUCING_MEMORY_USE">REDUCING MEMORY USE
</A></H1>
-As a side effect of using mod_perl, your
-<FONT SIZE=-1>HTTPD</FONT> processes will be larger than without it. There
-is just no way around it, as you have this extra code to support your added
-functionality.
+As a side effect of using mod_perl, your HTTPD processes will be larger
+than without it. There is just no way around it, as you have this extra
+code to support your added functionality.
<P>
-
-On a very busy site, the number of
-<FONT SIZE=-1>HTTPD</FONT> processes can grow to be quite large. For example, on one large site, the typical
-<FONT SIZE=-1>HTTPD</FONT> was about 5Mb large. With 30 of these, all of
-<FONT SIZE=-1>RAM</FONT> was exhausted, and we started to go to swap. With 60 of these, swapping turned into thrashing, and the whole machine slowed to a crawl.
+On a very busy site, the number of HTTPD processes can grow to be quite
+large. For example, on one large site, the typical HTTPD was about 5Mb
+large. With 30 of these, all of RAM was exhausted, and we started to go to
+swap. With 60 of these, swapping turned into thrashing, and the whole
+machine slowed to a crawl.
<P>
-To reduce thrashing, limiting the maximum number of
-<FONT SIZE=-1>HTTPD</FONT> processes to a number that is just larger than what will fit into
-<FONT SIZE=-1>RAM</FONT> (in this case, 45) is necessary. The drawback is that when the server is serving 45 requests, new requests will queue up and wait; however, if you let the maximum number of processes grow, the new requests will start to get served right away,
- <EM>but</EM> they will take much longer to complete.
+To reduce thrashing, limiting the maximum number of HTTPD processes to a
+number that is just larger than what will fit into RAM (in this case, 45)
+is necessary. The drawback is that when the server is serving 45 requests,
+new requests will queue up and wait; however, if you let the maximum number
+of processes grow, the new requests will start to get served right away, <EM>but</EM> they will take much longer to complete.
<P>
-One way to reduce the amount of real memory taken up by each process is to pre-load commonly used modules into the primary
-<FONT SIZE=-1>HTTPD</FONT> process so that the code is shared by all processes. This is accomplished by inserting the
- <CODE>use Foo ();</CODE> lines into the <EM>startup.perl</EM> file for any <CODE>use Foo;</CODE> statement in any commonly used Registry program. The idea is that the operating system's
-<FONT SIZE=-1>VM</FONT> subsystem will share the data across the processes.
+One way to reduce the amount of real memory taken up by each process is to
+pre-load commonly used modules into the primary HTTPD process so that the
+code is shared by all processes. This is accomplished by inserting the <CODE>use Foo ();</CODE> lines into the <EM>startup.perl</EM> file for any <CODE>use Foo;</CODE> statement in any commonly used Registry program. The idea is that the
+operating system's VM subsystem will share the data across the processes.
-
<P>
You can also pre-load Apache::Registry programs using the
-<CODE>Apache::RegistryLoader</CODE> module so that the code for these programs is shared by all
-<FONT SIZE=-1>HTTPD</FONT> processes as well.
+<CODE>Apache::RegistryLoader</CODE> module so that the code for these programs is shared by all HTTPD processes
+as well.
<P>
-
-<STRONG>NOTE</STRONG>: When you pre-load modules in the startup script, you may need to kill and restart
-<FONT SIZE=-1>HTTPD</FONT> for changes to take effect.
-<FONT SIZE=-1>A</FONT> simple
+<STRONG>NOTE</STRONG>: When you pre-load modules in the startup script, you may need to kill and
+restart HTTPD for changes to take effect. A simple
<CODE>kill -HUP</CODE> or <CODE>kill -USR1</CODE> will not reload that code unless you have set the <CODE>PerlFreshRestart</CODE> configuration parameter in
<EM>httpd.conf</EM> to be ``On''.
@@ -320,30 +309,30 @@
<H1><A NAME="REDUCING_THE_NUMBER_OF_LARGE_PRO">REDUCING THE NUMBER OF LARGE PROCESSES
</A></H1>
-Unfortunately, simply reducing the size of each
-<FONT SIZE=-1>HTTPD</FONT> process is not enough on a very busy site. You also need to reduce the quantity of these processes. This reduces memory consumption even more, and results in fewer processes fighting for the attention of the
-<FONT SIZE=-1>CPU.</FONT> If you can reduce the quantity of processes to fit into
-<FONT SIZE=-1>RAM,</FONT> your response time is increased even more.
-
+Unfortunately, simply reducing the size of each HTTPD process is not enough
+on a very busy site. You also need to reduce the quantity of these
+processes. This reduces memory consumption even more, and results in fewer
+processes fighting for the attention of the CPU. If you can reduce the
+quantity of processes to fit into RAM, your response time is increased even
+more.
<P>
-The idea of the techniques outlined below is to offload the normal document delivery (such as static
-<FONT SIZE=-1>HTML</FONT> and
-<FONT SIZE=-1>GIF</FONT> files) from the mod_perl
-<FONT SIZE=-1>HTTPD,</FONT> and let it only handle the mod_perl requests. This way, your large mod_perl
-<FONT SIZE=-1>HTTPD</FONT> processes are not tied up delivering simple content when a smaller process could perform the same job more efficiently.
+The idea of the techniques outlined below is to offload the normal 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.
-
<P>
-
-In the techniques below where there are two
-<FONT SIZE=-1>HTTPD</FONT> configurations, the same httpd executable can be used for both configurations; there is no need to build
-<FONT SIZE=-1>HTTPD</FONT> both with and without mod_perl compiled into it. With Apache 1.3 this can be done with the
-<FONT SIZE=-1>DSO</FONT> configuration -- just configure one httpd invocation to dynamically load mod_perl and the other not to do so.
+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.
<P>
@@ -361,14 +350,14 @@
<H2><A NAME="TWO_MACHINES">TWO MACHINES
</A></H2>
-The simplest way is to put all static content on one machine, and all mod_perl programs on another. The only trick is to make sure all links are properly coded to refer to the proper host. The static content will be served up by lots of small
-<FONT SIZE=-1>HTTPD</FONT> processes (configured
-
-<EM>not</EM> to use mod_perl), and the relatively few mod_perl requests can be handled by the smaller number of large
-<FONT SIZE=-1>HTTPD</FONT> processes on the other machine.
+The simplest way is to put all static content on one machine, and all
+mod_perl programs on another. The only trick is to make sure all links are
+properly coded to refer to the proper host. The static content will be
+served up by lots of small HTTPD processes (configured
+<EM>not</EM> to use mod_perl), and the relatively few mod_perl requests can be handled
+by the smaller number of large HTTPD processes on the other machine.
-
<P>
The drawback is that you must maintain two machines, and this can get
@@ -382,24 +371,20 @@
<H2><A NAME="TWO_IP_ADDRESSES">TWO IP ADDRESSES
</A></H2>
-Similar to above, but one
-<FONT SIZE=-1>HTTPD</FONT> runs bound to one
-<FONT SIZE=-1>IP</FONT> address, while the other runs bound to another
-<FONT SIZE=-1>IP</FONT> address. The only difference is that one machine runs both servers. Total memory usage is reduced because the majority of files are served by the smaller
-<FONT SIZE=-1>HTTPD</FONT> processes, so there are fewer large mod_perl
-<FONT SIZE=-1>HTTPD</FONT> processes sitting around.
-
+Similar to above, but one HTTPD runs bound to one IP address, while the
+other runs bound to another IP address. The only difference is that one
+machine runs both servers. Total memory usage is reduced because the
+majority of files are served by the smaller HTTPD processes, so there are
+fewer large mod_perl HTTPD processes sitting around.
<P>
This is accomplished using the <EM>httpd.conf</EM> directive <CODE>BindAddress</CODE>
-to make each
-<FONT SIZE=-1>HTTPD</FONT> respond only to one
-<FONT SIZE=-1>IP</FONT> address on this host. One will have mod_perl enabled, and the other will not.
+to make each HTTPD respond only to one IP address on this host. One will
+have mod_perl enabled, and the other will not.
-
<P>
<P>
@@ -407,10 +392,9 @@
<H2><A NAME="TWO_PORT_NUMBERS">TWO PORT NUMBERS
</A></H2>
-If you cannot get two
-<FONT SIZE=-1>IP</FONT> addresses, you can also split the
-<FONT SIZE=-1>HTTPD</FONT> processes as above by putting one on the standard port 80, and the other on some other port, such as 8042. The only configuration changes will be the
- <CODE>Port</CODE> and log file directives in the httpd.conf file (and also one of them does
+If you cannot get two IP addresses, you can also split the HTTPD processes
+as above by putting one on the standard port 80, and the other on some
+other port, such as 8042. The only configuration changes will be the <CODE>Port</CODE> and log file directives in the httpd.conf file (and also one of them does
not have any mod_perl directives).
@@ -422,11 +406,11 @@
<P>
-
-If you use this approach or the one above with dual
-<FONT SIZE=-1>IP</FONT> addresses, you probably do not want to have the *.perl and *.rperl sections from the sample configuration above, as this would require that your primary
-<FONT SIZE=-1>HTTPD</FONT> server be mod_perl enabled as well.
+If you use this approach or the one above with dual IP addresses, you
+probably do not want to have the *.perl and *.rperl sections from the
+sample configuration above, as this would require that your primary HTTPD
+server be mod_perl enabled as well.
<P>
@@ -441,11 +425,11 @@
<H2><A NAME="USING_ProxyPass_WITH_TWO_SERVERS">USING ProxyPass WITH TWO SERVERS
</A></H2>
-To overcome the limitation of the alternate port above, you can use dual Apache
-<FONT SIZE=-1>HTTPD</FONT> servers with just slight difference in configuration. Essentially, you set up two servers just as you would with the two port on same
-<FONT SIZE=-1>IP</FONT> address method above. However, in your primary
-<FONT SIZE=-1>HTTPD</FONT> configuration you add a line like this:
-
+To overcome the limitation of the alternate port above, you can use dual
+Apache HTTPD servers with just slight difference in configuration.
+Essentially, you set up two servers just as you would with the two port on
+same IP address method above. However, in your primary HTTPD configuration
+you add a line like this:
<P>
@@ -455,20 +439,23 @@
<P>
-Where your mod_perl enabled
-<FONT SIZE=-1>HTTPD</FONT> is running on port 8042, and has only the
+Where your mod_perl enabled HTTPD is running on port 8042, and has only the
directory <EM>programs</EM> within its DocumentRoot. This assumes that you have included the mod_proxy
module in your server when it was built.
<P>
-Now, when you access <A HREF="http://www.domain.com/programs/printenv">http://www.domain.com/programs/printenv</A> it will internally be passed through to your
-<FONT SIZE=-1>HTTPD</FONT> running on port 8042 as the
-<FONT SIZE=-1>URL</FONT> <A HREF="http://localhost:8042/programs/printenv">http://localhost:8042/programs/printenv</A> and the result relayed back transparently. To the client, it all seems as if it is just one server running. This can also be used on the dual-host version to hide the second server from view if desired.
+Now, when you access <A
+HREF="http://www.domain.com/programs/printenv">http://www.domain.com/programs/printenv</A>
+it will internally be passed through to your HTTPD running on port 8042 as
+the URL <A
+HREF="http://localhost:8042/programs/printenv">http://localhost:8042/programs/printenv</A>
+and the result relayed back transparently. To the client, it all seems as
+if it is just one server running. This can also be used on the dual-host
+version to hide the second server from view if desired.
-
<P>
<P>
@@ -481,8 +468,7 @@
The directory structure assumes that <EM>/var/www/documents</EM> is the
<CODE>DocumentRoot</CODE> directory, and the the mod_perl programs are in
-<EM>/var/www/programs</EM> and <EM>/var/www/rprograms</EM>.
-<FONT SIZE=-1>I</FONT> start them as follows:
+<EM>/var/www/programs</EM> and <EM>/var/www/rprograms</EM>. I start them as follows:
<P>
@@ -503,27 +489,33 @@
<H2><A NAME="SQUID_ACCELERATOR">SQUID ACCELERATOR
</A></H2>
-Another approach to reducing the number of large
-<FONT SIZE=-1>HTTPD</FONT> processes on one machine is to use an accelerator such as Squid (which can be found at <A HREF="http://squid.nlanr.net/Squid/">http://squid.nlanr.net/Squid/</A> on the web) between the clients and your large mod_perl
-<FONT SIZE=-1>HTTPD</FONT> processes. The idea here is that squid will handle the static objects from its cache while the
-<FONT SIZE=-1>HTTPD</FONT> processes will handle mostly just the mod_perl requests once the cache is primed. This reduces the number of
-<FONT SIZE=-1>HTTPD</FONT> processes and thus reduces the amount of memory used.
-
+Another approach to reducing the number of large HTTPD processes on one
+machine is to use an accelerator such as Squid (which can be found at <A
+HREF="http://squid.nlanr.net/Squid/">http://squid.nlanr.net/Squid/</A> 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.
<P>
-To set this up, just install the current version of Squid (at this writing, this is version 1.1.20) and use the RunAccel script to start it. You will need to reconfigure your
-<FONT SIZE=-1>HTTPD</FONT> to use an alternate port, such as 8042, rather than its default port 80. To do this, just change the
- <EM>httpd.conf</EM> line <CODE>Port</CODE> to match the port specified in the <EM>squid.conf</EM> file. Your URLs do not need to change.
+To set this up, just install the current version of Squid (at this writing,
+this is version 1.1.22) 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, you can either change the <EM>httpd.conf</EM> line <CODE>Port</CODE> or add a <CODE>Listen</CODE>
+directive to match the port specified in the <EM>squid.conf</EM> file. Your URLs do not need to change. The benefit of using the <CODE>Listen</CODE>
+directive is that redirected URLs will still use the default port 80 rather
+than your alternate port, which might reveal your real server location to
+the outside world and bypass the accelerator.
<P>
In the <EM>squid.conf</EM> file, you will probably want to add <CODE>programs</CODE>
-and <CODE>perl</CODE> to the <CODE>cache_stoplist</CODE> parameter so that these are always passed through to the
-<FONT SIZE=-1>HTTPD</FONT> server under the assumption that they always
-produce different results.
+and <CODE>perl</CODE> to the <CODE>cache_stoplist</CODE> parameter so that these are always passed through to the HTTPD server under
+the assumption that they always produce different results.
<P>
@@ -536,14 +528,64 @@
<P>
+One drawback to using this accelerator is that the logfiles will always
+report access from IP address 127.0.0.1, which is the local host loopback
+address. Also, any access permissions or other user tracking that requires
+the remote IP address will always see the local address. The following code
+uses a feature of recent mod_perl versions (tested with mod_perl 1.16 and
+Apache 1.3.3) to trick Apache into logging the real client address and
+giving that information to mod_perl programs for their purposes.
+
+
+<P>
+
+First, in your <EM>startup.perl</EM> file add the following code:
+
+
+<P>
+
+<PRE> use Apache::Constants qw(OK);
+
+ sub My::SquidRemoteAddr ($) {
+ my $r = shift;
+
+ my @ip = split(/,\s*/, $r->header_in('X-Forwarded-For'));
+ if (my $ip = pop(@ip)) {
+ $r->connection->remote_ip($ip);
+ }
+
+ return OK;
+ }
+</PRE>
+
+<P>
+
+Next, add this to your <EM>httpd.conf</EM> file:
+
+
+<P>
+
+<PRE> PerlPostReadRequestHandler My::SquidRemoteAddr
+</PRE>
+
<P>
+
+This will cause every request to have its <CODE>remote_ip</CODE> address overridden by the value set in the <CODE>X-Forwarded-For</CODE> header added by Squid.
+
+
+<P>
+
+<P>
<HR>
<H1><A NAME="SUMMARY">SUMMARY
</A></H1>
-To gain maximal performance of mod_perl on a busy site, one must reduce the amount of resources used by the
-<FONT SIZE=-1>HTTPD</FONT> to fit within what the machine has available. The best way to do this is to reduce memory usage. If your mod_perl requests are fewer than your static page requests, then splitting the servers into mod_perl and non-mod_perl versions further allows you to tune the amount of resources used by each type of request. Using the
- <CODE>ProxyPass</CODE>
+To gain maximal performance of mod_perl on a busy site, one must reduce the
+amount of resources used by the HTTPD to fit within what the machine has
+available. The best way to do this is to reduce memory usage. If your
+mod_perl requests are fewer than your static page requests, then splitting
+the servers into mod_perl and non-mod_perl versions further allows you to
+tune the amount of resources used by each type of request. Using the <CODE>ProxyPass</CODE>
directive allows these multiple servers to appear as one to the users.
Using the Squid accelerator also achieves this effect, but Squid takes care
of deciding when to acccess the large server automatically.
@@ -570,29 +612,30 @@
<P>
-This document is copyright © 1997-1998 by Vivek Khera.
+This document is copyright (c) 1997-1998 by Vivek Khera.
<P>
-
-If you have contributions for this document, please post them to the mailing list. Perl
-<FONT SIZE=-1>POD</FONT> format is best, but plain text will do, too.
+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.
<P>
If you need assistance, contact the mod_perl mailing list at <A
-HREF="MAILTO:modperl@apache.org">modperl@apache.org</A> first. There are
-lots of people there that can help. Also, check the web pages <A
-HREF="http://perl.apache.org/">http://perl.apache.org/</A> and <A
-HREF="http://www.apache.org/">http://www.apache.org/</A> for explanations
-of the configuration options.
+HREF="MAILTO:modperl@apache.org">modperl@apache.org</A> first (send
+'subscribe' to <A
+HREF="MAILTO:modperl-request@apache.org">modperl-request@apache.org</A> to
+subscribe). There are lots of people there that can help. Also, check the
+web pages <A HREF="http://perl.apache.org/">http://perl.apache.org/</A> and
+<A HREF="http://www.apache.org/">http://www.apache.org/</A> for
+explanations of the configuration options.
<P>
-$Revision: 1.2 $ $Date: 1998/06/12 19:03:20 $
+$Revision: 1.3 $ $Date: 1998/12/07 16:21:23 $
<P>