The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.


CGI::SpeedyCGI - Speed up perl CGI scripts by running them persistently



 ### Your CGI Script Here
 print "Content-type: text/html\n\nHello World!\n";

 ## Optionally, use the CGI::SpeedyCGI module for various things

 # Create a SpeedyCGI object
 use CGI::SpeedyCGI;
 my $sp = CGI::SpeedyCGI->new;

 # See if we are running under SpeedyCGI or not.
 print "Running under speedy=", $sp->i_am_speedy ? 'yes' : 'no', "\n";

 # Register a shutdown handler
 $sp->add_shutdown_handler(sub { do something here });

 # Register a cleanup handler
 $sp->register_cleanup(sub { do something here });

 # Set/get some SpeedyCGI options
 $sp->setopt('timeout', 30);
 print "maxruns=", $sp->getopt('maxruns'), "\n";


SpeedyCGI is a way to run CGI perl scripts persistently, which usually makes them run much more quickly. A script can be converted to SpeedyCGI by changing the interpreter line at the top of the script from:




After the script is initially run, instead of exiting, SpeedyCGI keeps the perl interpreter running. During subsequent runs, this interpreter is used to handle new requests instead of starting a new perl interpreter for each execution.

SpeedyCGI conforms to the CGI specification, and normally does not work inside the web server. A very fast cgi-bin, written in C, is executed for each request. This fast cgi-bin then contacts the persistent Perl process, which is usually already running, to do the work and return the results.

Since the perl interpreter runs outside the web server, it can't cause problems for the web server itself. By default each perl script runs in its own Unix process, so one program can't interfere with another. Command line options can also be used to deal with programs that have memory leaks or other problems that might keep them from otherwise running persistently.

SpeedyCGI also provides an Apache module so that under the Apache web server, scripts can be run without the overhead of doing a fork/exec for each request. With this module a small amount of frontend code is run within the web server - the perl interpreters still run outside the server.


Setting Option Values

SpeedyCGI options can be set in several ways:

Command Line

The speedy command line is the same as for regular perl, with the exception that SpeedyCGI specific options can be passed in after a "--".

For example the line:

        #!/usr/bin/speedy -w -- -t300

at the top of your script will set the perl option "-w" and will pass the "-t" option to SpeedyCGI, setting the Timeout value to 300 seconds.


Environment variables can be used to pass in options. This can only be done before the initial execution, not from within the script itself. The name of the environment variable is always SPEEDY_ followed by the option name in upper-case. For example to set the speedy Timeout option, use the environment variable named SPEEDY_TIMEOUT.


The CGI::SpeedyCGI module provides the setopt method to set options from within the perl script at runtime. There is also a getopt method to retrieve the current options. See "METHODS" below.


If you are using the optional Apache module, SpeedyCGI options can be set in the httpd.conf file. The name of the apache directive will always be Speedy followed by the option name. For example to set the Timeout option, use the apache directive SpeedyTimeout.


Not all options below are available in all contexts. The context for which each option is valid is listed on the "Context" line in the section below. There are three contexts:


The command-line "speedy" program, used normally with #! at the top of your script or from a shell prompt.


The optional Apache mod_speedycgi module.


During perl execution via the CGI::SpeedyCGI module's getopt/setopt methods.

Options Available

    Command Line    : -p<string>
    Default Value   : "/usr/local/bin/speedy_backend"
    Context         : mod_speedycgi, speedy


        Path to the speedy backend program.
    Command Line    : -B<number>
    Default Value   : 8192
    Context         : speedy


        Use <number> bytes for the buffer that receives data from
        the CGI script.
    Command Line    : -b<number>
    Default Value   : 1024
    Context         : speedy


        Use <number> bytes for the buffer that sends data to the
        CGI script.
    Command Line    : -g<string>
    Default Value   : "none"
    Context         : mod_speedycgi, speedy


        Allow a single perl interpreter to run multiple scripts.
        All scripts that are run with the same group name and by
        the same user will be run by the same group of perl
        interpreters. If the group name is "none" then grouping is
        disabled and each interpreter will run one script.
        Different group names allow scripts to be separated into
        different groups. Name is case-sensitive, and only the
        first 12-characters are significant. Specifying an empty
        group name is the same as specifying the group name
        "default" - this allows just specifying "-g" on the command
        line to turn on grouping.
    Command Line    : -M<number>
    Default Value   : 0 (no max)
    Context         : mod_speedycgi, speedy


        If non-zero, limits the number of speedy backends running
        for this cgi script to <number>.
    Command Line    : -r<number>
    Default Value   : 500
    Context         : mod_speedycgi, module, speedy


        Once the perl interpreter has run <number> times, re-exec
        the backend process.  Zero indicates no maximum.  This
        option is useful for processes that tend to consume
        resources over time.
    Command Line    : N/A
    Default Value   : ""
    Context         : mod_speedycgi


        Command-line options to pass to the perl interpreter.
    Command Line    : -t<number>
    Default Value   : 3600 (one hour)
    Context         : mod_speedycgi, module, speedy


        If no new requests have been received after <number>
        seconds, exit the persistent perl interpreter.  Zero
        indicates no timeout.
    Command Line    : -T<string>
    Default Value   : "/tmp/speedy"
    Context         : mod_speedycgi, speedy


        Use the given prefix for creating temporary files.  This
        must be a filename prefix, not a directory name.
    Command Line    : -v
    Context         : speedy


        Print the SpeedyCGI version and exit.


The following methods are available in the CGI::SpeedyCGI module.


Create a new CGI::SpeedyCGI object.

    my $sp = CGI::SpeedyCGI->new;

Register a function that will be called at the end of each request, after your script finishes running, but before STDOUT and STDERR are closed. Multiple functions can be added by calling the method more than once. At the end of the request, each function will be called in the order in which it was registered.


Add a function to the list of functions that will be called right before the perl interpreter exits. This is not at the end of each request, it is when the perl interpreter decides to exit completely due to a Timeout or reaching MaxRuns.

    $sp->add_shutdown_handler(sub {$dbh->logout});

Deprecated. Similar to add_shutdown_handler, but only allows for a single function to be registered.

    $sp->set_shutdown_handler(sub {$dbh->logout});

Returns a boolean telling whether this script is running under SpeedyCGI or not. A CGI script can run under regular perl, or under SpeedyCGI. This method allows the script to tell which environment it is in.


To make your script as portable as possible, you can use the following test to make sure both the SpeedyCGI module is available and you are running under SpeedyCGI:

    if (eval {require CGI::SpeedyCGI} && CGI::SpeedyCGI->i_am_speedy) {
        Do something SpeedyCGI specific here...

To increase the speed of this check you can also test whether the following variable is defined instead of going through the object interface:

setopt($optname, $value)

Set one of the SpeedyCGI options given in "Options Available". Returns the option's previous value. $optname is case-insensitive.

    $sp->setopt('TIMEOUT', 300);

Return the current value of one of the SpeedyCGI options. $optname is case-insensitive.


Shut down the perl interpreter right away. This function does not return.


Shut down the perl interpreter as soon as this request is done.



To install SpeedyCGI you will need to either download a binary package for your OS, or compile SpeedyCGI from source code. See "DOWNLOADING" for information on where to obtain the source code and binaries.

Binary Installation

Once you have downloaded the binary package for your OS, you'll need to install it using the normal package tools for your OS. The commands to do that are:

 rpm -i <filename>
 gunzip <filename>.gz
 pkgadd -d <filename>
 pkg_add <filename>

If you are also installing the apache module you will have to configure Apache as documented in "Apache Configuration".

Source Code Installation

To compile SpeedyCGI you will need perl 5.004 or later, and a C compiler, preferably the same one that your perl distribution was compiled with. SpeedyCGI is known to work under Solaris, Redhat Linux, FreeBSD and OpenBSD. There may be problems with other OSes or earlier versions of Perl. SpeedyCGI may not work with threaded perl -- as of release 2.10, Linux and Solaris seem to work OK with threaded perl, but FreeBSD does not.

Standard Install

To do a standard install from source code, execute the following:

    perl Makefile.PL
    make test
    make install

This will install the speedy and speedy_backend binaries in the same directory where perl was installed, and the module in the standard perl lib directory. It will also attempt to install the mod_speedycgi module if you have the command apxs in your path.

Install in a Different Directory

To install in a different directory, change the first line in "Standard Install" to:

    perl Makefile.PL PREFIX=/somewhere

This will install the binaries in /somewhere/bin and the module under /somewhere/lib.

Apache Installation

To compile the optional apache mod_speedycgi module you must have the apxs command in your path. Redhat includes this command with the "apache-devel" RPM, though it may not work properly for installation.

If the apache installation fails:

  • Copy the from the mod_speedycgi directory to wherever your apache modules are stored (try /usr/lib/apache)

  • Edit your httpd.conf (try /etc/httpd/conf/httpd.conf) and add the following lines. The path at the end of the LoadModule directive may be different in your installation -- look at other LoadModules to see.

        LoadModule speedycgi_module modules/
        AddModule mod_speedycgi.c

Apache Configuration

Once mod_speedycgi is installed, it has to be configured to be used for your perl scripts. There are two methods.

Warning! The instructions below may compromise the security of your web site. The security risks associated with SpeedyCGI are similar to those of regular CGI. If you don't understand the security implications of the changes below then don't make them.

1. Path Configuration

This is similar to the way /cgi-bin works - everything under this path is handled by SpeedyCGI. Add the following lines near the top of your httpd.conf - this will cause all scripts in your cgi-bin directory to be handled by SpeedyCGI when they are accessed as /speedy/script-name.

    Alias /speedy/ /home/httpd/cgi-bin/
    <Location /speedy>
        SetHandler speedycgi-script
        Options ExecCGI
        allow from all
2. File Extension Configuration

This will make SpeedyCGI handle all files with a certain extension, similar to the way .cgi files work. Add the following lines near the top of your httpd.conf file - this will set up the file extension ".speedy" to be handled by SpeedyCGI.

    AddHandler speedycgi-script .speedy
    <Location />
        Options ExecCGI


How does the speedy front end connect to the back end process?

Via a Unix socket in /tmp. A queue is kept in a shared file in /tmp that holds an entry for each process. In that queue are the pids of the perl processes waiting for connections. The CGI frontend pulls a process out of this queue, connects to its socket, sends over the environment and argv, and then uses this socket for stdin/stdout to the perl process.

If another request comes in while a CGI is running, does the client have to wait or is another process started? Is there a way to set a limit on how many processes get started?

If another request comes while all the perl processes are busy, then another perl process is started. Just like in CGI there is normally no limit on how many processes get started. But, the processes are only started when the load is so high that they're necessary. If the load goes down, the processes will die off due to inactivity, unless you disable the timeout.

Starting in version 1.8.3 an option was added to limit the number of perl backends running. See MaxBackends in "Options Available" above.

How much of perl's state is kept when speedy starts another request? Do globals keep their values? Are destructors run after the request?

Globals keep their values. Nothing is destroyed after the request. STDIN/STDOUT/STDERR are closed -- other files are not. %ENV, @ARGV, and %SIG are the only globals changed between requests.

How can I make sure speedy restarts when I edit a perl library used by the CGI?

Do a touch on the main cgi file that is executed. The mtime on the main file is checked each time the front-end runs.

Do I need to be root to install and/or run SpeedyCGI?

No, root is not required.

How can I determine if my perl app needs to be changed to work with speedy? Or is there no modification necessary?

You may have to make modifications.

Globals retain their values between runs, which can be good for keeping persistent database handles for example, or bad if your code assumes they're undefined.

Also, if you create global variables with "my", you shouldn't try to reference those variables from within a subroutine - you should pass them into the subroutine instead. Or better yet just declare global variables with "use vars" instead of "my" to avoid the problem altogether.

Here's a good explanation of the problem - it's for mod_perl, but the same thing applies to speedycgi:

If all else fails you can disable persistence by setting MaxRuns to 1. The only benefit of this over normal perl is that speedy will pre-compile your script between requests.

How do I keep a persistent connect to a database?

Since globals retain their values between runs, the best way to do this is to store the connection in a global variable, then check on each run to see if that variable is already defined.

For example, if your code has an "open_db_connection" subroutine that returns a database connection handle, you can use the code below to keep a persistent connection:

    use vars qw($dbh);
    unless (defined($dbh)) {
        $dbh = &open_db_connection;

This code will store a persistent database connection handle in the global variable "$dbh" and only initialize it the first time the code is run. During subsequent runs, the existing connection is re-used.

You may also want to check the connection each time before using it, in case it is not working for some reason. So, assuming you have a subroutine named "db_connection_ok" that returns true if the db connection is working, you can use code like this:

    use vars qw($dbh);
    unless (defined($dbh) && &db_connection_ok($dbh)) {
        $dbh = &open_db_connection;



Binaries for many OSes can be found at:

There are also some older debian packages available from:

The debian packages are not based on the latest version of SpeedyCGI.

Source Code

The standard source code distribution can be retrieved from any CPAN mirror or from:

The latest development code can be obtained from the SourceForge CVS repository using the following commands:

 cvs login 
 cvs -z3 co 2.x

Press Enter when prompted for a password.


    Sam Horrocks
    Daemon Consulting Inc.


perl(1), httpd(8), apxs(8).


SpeedyCGI Home Page

Mailing List

The mailing list address is Subscribe by sending a message to with the word "subscribe" in the body. An archive of the mailing list is at and mirrored at There is also a search interface at

Bugs and Todo List

Please report any bugs or requests for changes to the mailing list. The current bugs / todo list can be found at Go to the Bug Tracking menu and select the group "bug" for bugs, or the group "rfe" for the todo list.

Japanese Translation


Success Stories

Revision History


Copyright (C) 2001 Daemon Consulting Inc.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.