(You are Anonymous)

Performance Tuning for CGI::Application

CGI

The easiest way to use CGI::Application is (sigh!) as a CGI application. However, this approach is limited to low-traffic pages, because of the high demands it places on system ressources: For every invokation of a page served by CGI, the web server has to start a seperate process and collect its output. Afterwards, the CGI process is killed. For CGI::Application this means that for every request your web server has to start the Perl interpreter, read and compile your script plus all the modules it requires, maybe open database connections and read in template and configuration files.

when CGI is not fast enough

The most effective way to speed things up is to have a persistent Perl interpreter that stays around to handle more than just one request.

This significantly boosts web site performance by:

  • having to start your script (and Perl) only once
  • being able to keep database connections open for reuse in the next request
  • allowing you to cache things in memory easily (such as HTML::Template templates)

There are basically two ways to implement this: Mod Perl (which embeds Perl right into the Apache web server) and projects like Fast CGI or SpeedyCGI (which keep the Perl environment seperate from the web server).

Mod Perl

mod_perl creates a persistent Perl environment inside of the Apache web server. This means that Perl, your scripts and your modules run inside the web server itself. No external processes, loading and compiling of scripts and modules only once. Since mod_perl is so tightly integrated with Apache, you do not have to work exclusively with the CGI interface, you can also access internal Apache interfaces and data structures, allowing you to do much more than just handling page requests (such as URL rewriting, site authentication or custom logging).

Because of the memory requests and integration with the web server, mod_perl is offered by few hosting companies. However, if you project is big enough to need the performance enhancements of mod_perl, having your own server may make sense anyway.

Further mod_perl resources

FastCGI and SpeedyCGI

Your scripts are still external programs (which can be advantageous if you do not want to mess around too much with your web server) but once they are started, they keep running and can be reused from request to request.

The main advantage over Mod Perl is that your scripts are seperated from each other and from the web server itself, so that they cannot affect each other (whereas with mod_perl, you can accidentally bring the whole server down or introduce interesting side-effects into unrelated, but co-hosted scripts). This is essential if one server hosts many projects for many users. mod_perl 2 addresses these concerns by allowing Virtual Hosts to have their own Perl Interpreter. See apache configuration directives for 'Perl Options Clone' and 'Perl Options Parent'.

So if you are only looking for a performance boost for a CGI script (rather than wanting to hack up Apache in other ways, such as implementing custom logging) you should take FastCGI into account.

use strict;

One advantage of CGI is that it is very forgiving with sloppy programming: Since the process is discarded after every request, you cannot run into the problem that some data from the last request carries on into the current one (because you failed to declare your variables properly). This can cause headaches when migrating CGI scripts to either mod_perl or Fast CGI. But if you are using CGI::Application, you probably already write clean, strict code and will not run into trouble here.

See Also