Getting Started with mod_perl in 30 Minutes Page 7

On my machine it reports:

  /usr/lib/perl5/5.00503/i386-linux
  /usr/lib/perl5/5.00503
  /usr/lib/perl5/site_perl/5.005/i386-linux
  /usr/lib/perl5/site_perl/5.005
  .

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
  
    SetHandler perl-script
    PerlHandler ModPerl::Rules1
  

Now you can issue a request to:

  http://localhost/mod_perl_rules1

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

  mod_perl rules!

as the response.

To test the second module add the same
configuration, while replacing all 1’s with 2’s:

  PerlModule ModPerl::Rules2
  
    SetHandler perl-script
    PerlHandler ModPerl::Rules2
  

 And to test use the URI: 
  http://localhost/mod_perl_rules2

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.