The article starts with an overview of some of the known mod_perl deployment techniques. Then it dives into a list of pros and cons of the Standalone mod_perl Enabled Apache Server approach - the very basic one, it proceeds with installation process and ends up with basic configuration details.
If you did not reserve your sit on the upcoming 1999 O'Reilly Perl Conference 3.0 - this is the time. Seven concurrent conferences - Perl, Apache, Linux, Sendmail, Tcl/Tk, Python and OSS Business! Register at http://conference.oreilly.com/ .
Why attend the O'Reilly Open Source Convention?
Improve your programming or system administration skills
Meet the core developers for 6 key open-source technologies
Learn about the latest tools and techniques to help you work faster and smarter
Network with your peers
Get technical information without hype or sales pitches
Be part of a historic gathering of the open-source software community
Several apache conference tracks will talk explicitly about mod_perl, so if you want to learn mod_perl from the original sources you better be there :o)
There are several different ways to build, configure and deploy mod_perl enabled server. Some of them are:
Having one binary and one config file (one big binary for mod_perl).
Having two binaries and two config files (one big binary for mod_perl and one small for static objects like images.)
Having one DSO-style binary, mod_perl loadable object and two config files (Dynamic linking lets you compile once and have a big and a small binary in memory BUT you have to deal with a freshly made solution that has weak documentation and is still subject to change and is rather more complex.)
Any of the above plus a reverse proxy server in http accelerator mode.
If you are a newbie, I would recommend that you start with the first option and work on getting your feet wet with apache and mod_perl. Later, you can decide whether to move to the second one which allows better tuning at the expense of more complicated administration, or to the third option -- the more state-of-the-art-yet-suspiciously-new DSO system, or to the forth option which gives you even more power.
The first option will kill your production site if you serve a lot of static data with ~2-12 MB webserver processes. On the other hand, while testing you will have no other server interaction to mask or add to your errors.
The second option allows you to seriously tune the two servers for maximum performance. On the other hand you have to deal with proxying or fancy site design to keep the two servers in synchronization. In this configuration, you also need to choose between running the two servers on multiple ports, multiple IPs, etc... This adds the burden of administrating more than one server.
The third option (DSO) -- as mentioned above -- means playing with the
bleeding edge. In addition mod_so (the DSO module) adds size and complexity to your binaries. With DSO,
modules can be added and removed without recompiling the server, and
modules are even shared among multiple servers. Again, it is bleeding edge
and still somewhat platform specific, but your mileage may vary.
The fourth option (proxy in http accelerator mode), once correctly configured and tuned, improves performance by caching and buffering page results.
I will go through every of the presented above configurations, explain the pros and cons of each one, provide the installation and the configuration details.
Today we will start with the simplest configuration - One binary and one configuration file mod_perl server. In the following columns we will cover the rest of the configurations.
The first approach is to implement a straightforward mod_perl server. Just take your plain apache server and add mod_perl, like you add any other apache module. You continue to run it at the port it was running before. You probably want to try this before you proceed to more sophisticated and complex techniques.
The Advantages:
Simplicity. You just follow the installation instructions, configure it, restart the server and you are done.
No network changes. You do not have to worry about using additional ports as we will see later.
Speed. You get a very fast server, you see an enormous speedup from the first moment you start to use it.
The Disadvantages:
The process size of a mod_perl-enabled Apache server is huge (starting from 4Mb at startup and growing to 10Mb and more, depending on how you use it) compared to the typical plain Apache
You probably have a few tens of children processes. The additional memory requirements add up in direct relation to the number of children processes. Your memory demands are growing by an order of magnitude, but this is the price you pay for the additional performance boost of mod_perl. With memory prices so cheap nowadays, the additional cost is low -- especially when you consider the dramatic performance boost mod_perl gives to your services with every 100Mb of RAM you add.
While you will be happy to have these monster processes serving your scripts with monster speed, you should be very worried about having them serve static objects such as images and html files. Each static request served by a mod_perl-enabled server means another large process running, competing for system resources such as memory and CPU cycles. The real overhead depends on static objects request rate. Remember that if your mod_perl code produces HTML code which includes images, each one will turn into another static object request. Having another plain webserver to serve the static objects solves this not pleasant obstacle. Having a proxy server as a front end, caching the static objects and freeing the mod_perl processes from this burden is another solution. We will discuss both below.
Another drawback of this approach is that when serving output to a client with a slow connection, the huge mod_perl-enabled server process (with all of its system resources) will be tied up until the response is completely written to the client. While it might take a few milliseconds for your script to complete the request, there is a chance it will be still busy for some number of seconds or even minutes if the request is from a slow connection client. As in the previous drawback, a proxy solution can solve this problem. More on proxies later.
Proxying dynamic content is not going to help much if all the clients are on a fast local net (for example, if you are administering an Intranet.) On the contrary, it can decrease performance. Still, remember that some of your Intranet users might work from home through the slow modem links.
If you are new to mod_perl, this is probably the best way to get yourself started.
And of course, if your site is serving only mod_perl scripts (close to zero static objects, like images), this might be the perfect choice for you!
The Installation is very very simple (example from Linux OS):
% cd /usr/src % lwp-download http://www.apache.org/dist/apache_x.x.x.tar.gz % lwp-download http://perl.apache.org/dist/mod_perl-x.xx.tar.gz % tar zvxf apache_x.xx.tar.gz % tar zvxf mod_perl-x.xx.tar.gz % cd mod_perl-x.xx % perl Makefile.PL APACHE_SRC=../apache_x.x.x/src \ USE_APACI=1 DO_HTTPD=1 PERL_MARK_WHERE=1 ALL_HOOKS=1 % make && make test && make install % cd ../apache_x.x.x/src % make install
That's all!
Notes: Replace x.x.x with the real version numbers of mod_perl and apache. gnu tar uncompresses as well (with z flag).
First download the sources of both packages, e.g. you can use
lwp-download utility to do it. lwp-download is a part of the LWP (or libwww) package, you will need to have it
installed in order for mod_perl's make test to pass. Once you install this package unless it's already installed, lwp-download will be available for you as well.
% lwp-download http://www.apache.org/dist/apache_x.x.x.tar.gz % lwp-download http://perl.apache.org/dist/mod_perl-x.xx.tar.gz
Extract both sources. Generally I open all the sources in
/usr/src/, your mileage may vary. So move the sources and cd to the directory you
want to put the sources in. Gnu tar utility knows to uncompress too with z flag, if you have a non-gnu tar utility, it will be incapable to decompress, so you would do it in 2 steps,
first uncompressing the packages with gzip -d apache_x.xx.tar.gz and
gzip -d mod_perl-x.xx.tar.gz. And untarring them with tar xvf
apache_x.xx.tar and tar xvf mod_perl-x.xx.tar.
% cd /usr/src % tar zvxf apache_x.xx.tar.gz % tar zvxf mod_perl-x.xx.tar.gz
Change to the mod_perl source directory.
% cd mod_perl-x.xx
Now build the make file, for a basic work and first time installation the
parameters in the example below are the only ones you would need. APACHE_SRC tells where the apache <src> directory is. If you have followed my
advice and extracted the sources under the same directory (e.g.
</usr/src>), the following is correct.
% perl Makefile.PL APACHE_SRC=../apache_x.x.x/src \
USE_APACI=1 DO_HTTPD=1 PERL_MARK_WHERE=1 ALL_HOOKS=1
There are many additional parameters. I will cover them in the future
articles, when they will become relevant. While running perl
Makefile.PL ... the process will check for prerequisites and tell you if something is
missing, If you are missing some of the perl packages or other software you
will have to install these before you proceed.
Now we make the project (by building the mod_perl extension and calling make in apache source directory to build a httpd),
make test it (by running various tests) and install the mod_perl modules.
% make && make test && make install
Note that if make fails, non of the make test and make
install will be not executed. If make test fails, make install
will be not executed.
Now change to apache source directory and run make install to install apache's headers, default configuration files, build apache
directory tree and put the httpd there.
% cd ../apache_x.x.x/src % make install
When you execute the above command, apache installation process will tell you how can you start the webserver (the path of the <apachectl>, more about it later) and where the configuration files are. Remember (or even better write down) both for you will need this information very soon. On my machine they 2 important paths are:
/usr/local/apache/bin/apachectl /usr/local/apache/conf/httpd.conf
Now the build and the installation processes are completed. Just configure httpd.conf and start the webserver.
A basic configuration is a simple one. First configure the apache as you
always do (like setting a correct Port, User, Group, log-file and other file paths and etc), start the server and make sure it
works. One of the ways to start and stop the server is to use
apachectl utility:
/usr/local/apache/bin/apachectl start /usr/local/apache/bin/apachectl stop
Put the server down, open the httpd.conf in your favorite editor and scroll to the end of the file, where we will
add the mod_perl configuration directives (of course you can place them
anywhere in the file).
Add the following configuration directives:
Alias /perl/ /home/httpd/perl/
Assuming that you put all your scripts that should be executed under
mod_perl into /home/httpd/perl/ directory.
PerlModule Apache::Registry
<Location /perl>
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
PerlSendHeader On
allow from all
</Location>
Now put a test script into /home/httpd/perl/ directory:
test.pl ------- #!/usr/bin/perl -w use strict; print "Content-type: text/html\r\n\r\n"; print "It worked!!!\n"; -------
Make it executable and readable by server, if your server is running as
user nobody (hint see User directive in httpd.conf file), do the following:
chown nobody /home/httpd/perl/test.pl chmod u+rx /home/httpd/perl/test.pl
Test that the script is running from the command line, by executing it:
/home/httpd/perl/test.pl
You should see:
Content-type: text/html It worked!!!
Now it is a time to test our mod_perl server, assuming that your config
file includes Port 80, go to your favorite Netscape browser and fetch the following URL:
http://localhost/perl/test.pl
(Assuming that you have a loop-back device configured, if not use the real
server name for this test (e.g. http://www.nowhere.com/perl/test.pl)
You should see:
It worked!!!
If something went wrong, go through the installation process again, and
make sure you didn't make a mistake. If that doesn't help, read the INSTALL pod document (perlpod INSTALL) in the mod_perl distribution directory.
Now migrate your CGI scripts into a /home/httpd/perl/ directory and see them working much much faster, from the newly configured
base URL (/perl/). Not all of your scripts will work unmodified, but most should work
unchanged.
In the future articles I will explain the meaning of the configuration parameters, present not yet seen ones, cover the porting process of CGI scripts to mod_perl and many other very important issues. The above setup is very basic, it will help you to have a mod_perl enabled server running.
As with perl you can start benefit from mod_perl from the very first moment you try it. When you become more familiar with mod_perl you will want to start writing apache handlers and deploy more of the mod_perl power.