CGI::SpeedyCGI - Speed up perl CGI scripts by running them persistently
#!/usr/local/bin/speedy
### 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";
# Set up a shutdown handler $sp->set_shutdown_handler(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. Converting scripts to use SpeedyCGI is in many cases as simple has changing the interpreter line at the top of the script from
#!/usr/local/bin/perl
to
#!/usr/local/bin/speedy
After the script is initially run, instead of exiting, SpeedyCGI keeps the perl interpreter running in memory. 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 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 in memory, to do the work and return the results.
Since all of these processes run outside the web server, they can't cause problems for the web server itself. Also, each perl program runs as 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 options can be set in several ways:
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/local/bin/speedy -w -- -t300
at the top of your script will call SpeedyCGI with the perl option ``-w
'' and will pass the ``-t
'' option to speedy, setting the Timeout option 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 speedy 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.
Command Line : -pstr Default Value : /usr/bin/speedy_backend Context : mod_speedycgi, speedy
Description:
Path to the speedy backend program.
Command Line : -BN Default Value : 8192 Context : speedy
Description:
Use this many bytes for the buffer that receives data from the CGI script.
Command Line : -bN Default Value : 1024 Context : speedy
Description:
Use this many bytes for the buffer that sends data to the CGI script.
Command Line : -MN Default Value : 0 (no max) Context : mod_speedycgi, speedy
Description:
If non-zero, limits the number of speedy backends running for this cgi script to this value.
Command Line : -rN Default Value : 0 (no max) Context : mod_speedycgi, module, speedy
Description:
Once the perl interpreter has run this many 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
Description:
Command-line options to pass to the perl interpreter.
Command Line : -tN Default Value : 3600 (one hour) Context : mod_speedycgi, module, speedy
Description:
If no new requests have been received after this many seconds, exit the persistent perl interpreter. Zero indicates no timeout.
Command Line : -Tstr Default Value : /tmp/speedy Context : mod_speedycgi, speedy
Description:
Use the given prefix for creating temporary files. This must be a filename prefix, not a directory name.
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 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, maxruns, etc)
$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.
$sp->i_am_speedy;
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.
$sp->getopt('TIMEOUT');
SpeedyCGI has been tried with perl version 5.004_04 under Solaris 2.6 and version 5.005_03, under Redhat Linux 6.1. There may be problems with other OSes or earlier versions of Perl.
To install, do the following:
perl Makefile.PL make make test make install
This will install the speedy and speedy_backend binaries in the same directory where perl was installed, and the SpeedyCGI.pm module in the standard perl lib directory. It will also attempt to install the mod_speedycgi module if you have ``apxs'' in your path.
To install in a different directory, change the first line in the standard install to:
perl Makefile.PL PREFIX=/somewhere
This will install the binaries in /somewhere/bin and the SpeedyCGI.pm module under /somewhere/lib.
To use the optional apache mod_speedycgi module you must have the ``apxs'' command in your path. Redhat includes this command with the ``apache-devel'' RPM. Also, the apxs command may be broken for installing the module.
If the apache installation fails:
Copy the mod_speedycgi.so 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/mod_speedycgi.so AddModule mod_speedycgi.c
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.
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 </Location>
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 </Location>
Please report any bugs to speedycgi@newlug.org. Below is a list of known bugs:
On Solaris w/Netscape Enterprise 3.x, occasionally the CGI front-end gets
stuck in the poll()
call in speedy.c. The cause is unknown.
Via a Unix socket in /tmp. A queue is kept in /tmp that holds an entry for each process. In that queue are the pids of the perl processes waiting for connections. The CGI-front end 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 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.
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.
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.
No, root is not required.
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.
Here's a good explanation of the problem - it's for mod_perl, but the same thing applies to speedycgi:
http://perl.apache.org/faq/mod_perl_cgi.html#Variables_retain_their_value_fro
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.
Need benchmarks and feature comparison of speedy, mod_perl, fastcgi.
Pass file descriptors 0/1 to the Perl prog using I_SENDFD on systems that support it (like Solaris). Avoids the overhead of copying through the CGI front-end.
Need to allow more program control from perl via the CGI::SpeedyCGI module. Should be able to have the perl prog wait for a new connection, etc.
Add option to check the amount of memory in use and exit when it gets too high.
Port to Windows NT
See if all of the backend functions can be moved into the CGI::SpeedyCGI module, and then eliminate the separate speedy_backend binary and use the normal perl binary instead.
Enable the group option so a single interpreter can run multiple scripts. This feature is in the temp-file structure, but not yet implemented in code.
Add frontend disk caching so that slow clients don't tie up backends. This would be incompatible with I_SENDFD.
When invalidating a group, send an alarm signal to all frontends waiting in the queue.
speedycgi@newlug.org. Subscribe by sending a message to speedycgi-request@newlug.org with ``subscribe'' in the body.
Archive is at http://newlug.org/mailArchive/speedycgi
SpeedyCGI can be retrieved from:
http://daemoninc.com/speedycgi http://www.cpan.org/modules/by-authors/id/H/HO/HORROCKS/
Sam Horrocks Daemon Consulting Inc. http://daemoninc.com sam@daemoninc.com
perl(1),
httpd(8),
apxs(8).
Copyright (C) 2000 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.