A brief introduction to mod_perl - Part 1
Posted by Steve on Thu 30 Apr 2009 at 17:30
Apache is currently the world's most popular webserver. There are many alternative webservers, but Apache was one of the first which offered real control, flexibility, and numerous available extensions. With the introduction of mod_perl you can directly control almost every aspect of your webserver with pure Perl. Read on for a brief introduction to using mod_perl.
mod_perl is an extension to the Apache webserver which is installed in the same way as other external extensions are. What makes it different is that it exposes almost every aspect of the webserver to an embedded Perl interpreter allowing you to customize your server and write extensions in the Perl language, both quickly and easily.
Even if you never write an extension to your server you might still find mod_perl useful, as it allows you to speedup any Perl-based CGI scripts you might have running.
Installing mod_perl
Installing mod_perl is pretty straighforward, we just need to install the libapache2-mod-perl2 package:
lenny:~# apt-get install libapache2-mod-perl2 Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libapache2-reload-perl libbsd-resource-perl libperl5.10 The following NEW packages will be installed libapache2-mod-perl2 libapache2-reload-perl libbsd-resource-perl libperl5.10 0 upgraded, 4 newly installed, 0 to remove and 2 not upgraded. Need to get 1201kB of archives. After this operation, 3891kB of additional disk space will be used. ... Processing triggers for man-db ... Setting up libperl5.10 (5.10.0-19) ... Setting up libapache2-mod-perl2 (2.0.4-5) ... Enabling module perl. Run '/etc/init.d/apache2 restart' to activate new configuration! Setting up libapache2-reload-perl (0.10-2) ... Setting up libbsd-resource-perl (1.28-1+b1) ...As you can see the module was enabled, but if it wasn't you can do it manually (it won't hurt to run this twice), and then restart Apache:
lenny:~# a2enmod perl Module perl already enabled lenny:~# /etc/init.d/apache2 restart Restarting web server: apache2 ... waiting .Now the module is installed, but we've not configured it in any way. The simplest way to see an overview of what is happening is to add the perl-status handler. Create the file /etc/apache2/conf.d/perl-status with the following contents:
# # make status information available at # http://example.com/perl-status/ # <Location /perl-status> SetHandler perl-script PerlHandler +Apache2::Status </Location> # # But only from the local host, and our trusted # remote IP. # <Location /perl-status> order deny,allow deny from all allow from 127.0.0.1 allow from your.ip.address </Location>Once you've reloaded apache2 you should be able to visit your server's /perl-status page, and see several interesting things such as the server's environment and the list of loaded perl modules.
Note: This status page may easily expose private details of your server, which is why we restricted the clients which can access it. I'd strongly suggest you do the same if your server is accessible to the world.
If you've got this far you're doing well, and we can move on to doing something more useful.
Speeding up Perl CGI Scripts
Because mod_perl embeds a persistent copy of Perl inside the Apache webserver you can use this embedded copy of perl to run your existing perl-based CGI scripts faster. This speedup comes from avoiding the overhead of launching a new copy of the Perl interpreter when an incoming CGI request is to be handled, to get a more impressive speedup requires making changes to your script(s).
By default in Debian GNU/Linux system CGI-scripts are located in /usr/lib/cgi-bin - we can specify that Apache run these via mod_perl by making the following changes to our site configuration:
PerlModule Apache::Registry Alias /cgi-bin/ /usr/lib/cgi-bin <Location /cgi-bin> SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI </Location>Once you've done this, and reloaded the new configuration (by running "/etc/init.d/apache2 restart"), you find that your existing CGI scripts launch much more quickly!
This concludes our brief introduction to getting mod_perl installed and using it to speedup Perl-based CGI scripts.
In the next part we'll look at actually using mod_perl, developing a simple module that will ban clients that behave badly.
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
Old it might be, but still useful ..
[ Parent | Reply to this comment ]
May I know for the following configuration, where file it should be added? The article doesn't mentioned this :)
PerlModule Apache::Registry
Alias /cgi-bin/ /usr/lib/cgi-bin
<Location /cgi-bin>
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
Options +ExecCGI
</Location>
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
Add that to your site configuration file.
i.e. /etc/apache2/sites-enabled/your-site.conf - if you're using the suggested Debian layout. Whichever file you're VirtualHost bit is in anyway.
[ Parent | Reply to this comment ]
You are more than welcome to use any language you want, but today lots of high profile web sites run large systems using mod_perl. It is fast and stable with a rich environment.
I'll grant you it's not as popular with newbies as PHP or as trendy as Rails but it does have a better reputation for security and scalability.
All the dynamic "P" languages such as Perl, Python, Ruby and "PHP" may not be as enterprise/corporate as Java/c# but non the less they all work very well and are used an awful lot more than people think. We all know how to identify a Java site - it's slow and we all shudder when we see ASP dump MS SQL or c# stack dumps...
--
"It's Not Magic, It's Work"
Adam
[ Parent | Reply to this comment ]
apache2 + mod_perl2 is awesome. I recommend that you also install libapache2-mod-apreq2. Apache2::Request requires it and CGI will use it rather than native perl do processing of cookies etc.
If you are writing apps from scratch, consider scrapping Registry and writing your application as a handler. Youll see performance improvements again and significant reductions in code.
Of course you can use catalyst with mod_perl2 if you like MVC frameworks.
[ Parent | Reply to this comment ]
[Thu Apr 30 19:42:55 2009] [notice] SIGHUP received. Attempting to restart
[Thu Apr 30 19:42:55 2009] [error] Can't locate Apache/Registry.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl . /etc/apache2) at (eval 2) line 3.\n
[Thu Apr 30 19:42:55 2009] [error] Can't load Perl module Apache::Registry for server city-web-lnx:0, exiting...
And yet:
$ dpkg -l | grep apache | grep perl
ii libapache-dbi-perl 1.07-1 Connect apache server to database via perl's
ii libapache2-mod-perl2 2.0.4-5 Integration of perl with the Apache2 web ser
ii libapache2-reload-perl 0.10-2 Reload Perl modules when changed on disk
Am I missing something?
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
Try using ModPerl::Registry instead?
[ Parent | Reply to this comment ]