Getting Started with mod_perl in 30 Minutes Page 7

Download the authoritative guide: Data Center Guide: Optimizing Your Data Center Strategy

Download the authoritative guide: Cloud Computing: Using the Cloud for Competitive Advantage

On my machine it reports:


Now add the following snippet to httpd.conf to configure mod_perl to execute the ModPerl::Rules::handler subroutine whenever a request to mod_perl_rules1 is made:

  PerlModule ModPerl::Rules1
  <Location /mod_perl_rules1>
    SetHandler perl-script
    PerlHandler ModPerl::Rules1

Now you can issue a request to:


and just as with our mod_perl_rules.pl scripts you will see:

  mod_perl rules!

as the response.

To test the second module <ModPerl::Rules2> add the same configuration, while replacing all 1's with 2's:

  PerlModule ModPerl::Rules2
  <Location /mod_perl_rules2>
    SetHandler perl-script
    PerlHandler ModPerl::Rules2

And to test use the URI:


Is This All I Need to Know About mod_perl?

Obviously the next question you'll ask is: "Is this all I need to know about mod_perl?".

The answer is: Yes and No.

The Yes part:

  • Just like with Perl, you have to know very little about mod_perl to do really cool stuff. The presented setup allows you to run your visitor counters and guest book much faster and amaze your friends, usually without changing a single line of code.

The No part:

  • A 50 times improvement in guest book response times is great, but when you deploy a very heavy service with thousands of concurrent users, taking into account a high level competition between similar web services, a delay of a few milliseconds might cost you a customer and probably many of them.

    Of course when you test a single script and you are the only user, you don't really care about squeezing yet another millisecond from response time, but it becomes a real issue when these milliseconds add up at the production site, with hundreds of users concurrently generating requests to various scripts on your site. Users aren't merciful nowadays--if there is another even less fancier site that provides the same service but a little bit faster, chances are that they will go over there.

    Testing your scripts on an unloaded machine can be very misleading, Everything might seem so perfect. But when you move them into a production machine, things don't behave as well as they did on your development box. Many times you just run out of memory on very busy services. You need to learn how to optimize your code to use less memory and how to make the memory shared.

    Debugging is something people prefer not to talk about, since the process can be very tedious at times. Learning how to make the debugging process simpler and efficient is a must if you consider yourself a web programmer. This task is especially not so straightforward when debugging CGI scripts, and even more complicated with mod_perl. Unless you know how, and then it suddenly becomes easy.

    mod_perl has many features unavailable under mod_cgi when working with databases. Among others the most important are persistent connections.

    You have to know how to keep your service running non-stop and be able to recover fast if there are any problems.

This article was originally published on Jun 23, 2000

Thanks for your registration, follow us on our social networks to keep up-to-date