12.2 Standalone mod_perl-Enabled Apache Server
simplest scenario uses a straightforward, standalone,
mod_perl-enabled Apache server, as shown in Figure 12-1. Just take your plain Apache server and add
mod_perl, like you would add any other Apache module. Continue to run
it at the port it was using before. You probably want to try this
before you proceed to more sophisticated and complex techniques. This
is the standard installation procedure we described in Chapter 3.
Figure 12-1. mod_perl-enabled Apache server
A standalone server gives you the
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
You get a very fast server for dynamic content, and you see an
enormous speedup compared to mod_cgi, from the first moment you start
to use it.
The disadvantages of a standalone server are as follows:
The process size of a mod_perl-enabled
Apache server might be huge (maybe 4 MB at startup and growing to 10
MB or more, depending on how you use it) compared to a typical plain
Apache server (about 500 KB). Of course, if memory sharing is in
place, RAM requirements will be smaller.
You probably have a few dozen child processes. The additional
memory requirements add up in
direct relation to the number of child processes. Your memory demands
will grow by an order of magnitude, but this is the price you pay for
the additional performance boost of mod_perl. With memory being
relatively inexpensive nowadays, the additional cost is
low—especially when you consider the dramatic performance boost
mod_perl gives to your services with every 100 MB 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 the
static object request
rate. Remember that if your mod_perl code produces HTML code that
includes images, each of these will produce another static object
request. Having another plain web server to serve the static objects
solves this unpleasant problem. Having a proxy server as a frontend,
caching the static objects and freeing the mod_perl processes from
this burden, is another solution. We will discuss both later.
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 still be busy for a number of seconds or even minutes
if the request is from a client with a slow connection. As with the
previous drawback, a proxy solution can solve this problem.
We'll discuss proxies more 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 slow modem links.
If you are new to mod_perl, this is probably the best way to get
And of course, if your site is serving only mod_perl scripts (and
close to zero static objects), this might be the perfect choice for
Before trying the more advanced setup techniques we are going to talk
about now, it's probably a good idea to review the
simpler straightforward installation and configuration techniques
covered in Chapter 3 and Chapter 4. These will get you started with the standard
deployment discussed here.