PersistentPerl - Speed up perl scripts by running them persistently.
#!/usr/bin/perperl
### Your Script Here print "Content-type: text/html\n\nHello World!\n";
## ## Optionally, use the PersistentPerl module for various things ##
# Create a PersistentPerl object use PersistentPerl; my $pp = PersistentPerl->new;
# See if we are running under PersistentPerl or not. print "Running under perperl=", $pp->i_am_perperl ? 'yes' : 'no', "\n";
# Register a shutdown handler $pp->add_shutdown_handler(sub { do something here });
# Register a cleanup handler $pp->register_cleanup(sub { do something here });
# Set/get some PersistentPerl options $pp->setopt('timeout', 30); print "maxruns=", $pp->getopt('maxruns'), "\n";
PersistentPerl is a way to run perl scripts persistently, which can make them run much more quickly. A script can be made to to run persistently by changing the interpreter line at the top of the script from:
#!/usr/bin/perl
to
#!/usr/bin/perperl
After the script is initially run, instead of exiting, the perl interpreter is kept running. During subsequent runs, this interpreter is used to handle new executions instead of starting a new perl interpreter each time. A very fast frontend program, written in C, is executed for each request. This fast frontend then contacts the persistent Perl process, which is usually already running, to do the work and return the results.
By default each perl script runs in its own Unix process, so one perl script 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.
PersistentPerl can be used to speed up perl CGI scripts. It conforms to the CGI specification, and does not run perl code inside the web server. Since the perl interpreter runs outside the web server, it can't cause problems for the web server itself.
PersistentPerl 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.
SpeedyCGI and PersistentPerl are currently both names for the same code. SpeedyCGI was the original name, but because people weren't sure what it did, the name PersistentPerl was picked as an alias. At some point SpeedyCGI will probably be replaced by PersistentPerl, or become a sub-class of PersistentPerl to avoid always having two distributions.
PersistentPerl options can be set in several ways:
For example the line:
#!/usr/bin/perperl -w -- -t300
at the top of your script will set the perl option
``-w
'' and will pass the ``-t
'' option to PersistentPerl, setting the
Timeout value to 300 seconds.
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:
Command Line : -p<string> Default Value : "/home/sam/pkg/perl-5.8.0/bin/perperl_backend" Context : mod_persistentperl, perperl
Description:
Path to the perperl backend program.
Command Line : -B<number> Default Value : 131072 Context : perperl
Description:
Use <number> bytes as the maximum size for the buffer that receives data from the perl backend.
Command Line : -b<number> Default Value : 131072 Context : perperl
Description:
Use <number> bytes as the maximum size for the buffer that sends data to the perl backend.
Command Line : -g<string> Default Value : "none" Context : mod_persistentperl, perperl
Description:
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_persistentperl, perperl
Description:
If non-zero, limits the number of perperl backends running for this perl script to <number>.
Command Line : -r<number> Default Value : 500 Context : mod_persistentperl, module, perperl
Description:
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_persistentperl
Description:
Command-line options to pass to the perl interpreter.
Command Line : -t<number> Default Value : 3600 (one hour) Context : mod_persistentperl, module, perperl
Description:
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/perperl" Context : mod_persistentperl, perperl
Description:
Use the given prefix for creating temporary files. This must be a filename prefix, not a directory name.
Command Line : -v Context : perperl
Description:
Print the PersistentPerl version and exit.
The following methods are available in the PersistentPerl module.
my $pp = PersistentPerl->new;
register_cleanup($function_ref)
$pp->register_cleanup(\&cleanup_func);
add_shutdown_handler($function_ref)
$pp->add_shutdown_handler(sub {$dbh->logout});
set_shutdown_handler($function_ref)
add_shutdown_handler
, but only allows for a single
function to be registered.
$pp->set_shutdown_handler(sub {$dbh->logout});
$pp->i_am_perperl;
To make your script as portable as possible, you can use the following test to make sure both the PersistentPerl module is available and you are running under PersistentPerl:
if (eval {require PersistentPerl} && PersistentPerl->i_am_perperl) { Do something PersistentPerl 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:
$PersistentPerl::i_am_perperl
$pp->setopt('TIMEOUT', 300);
getopt($optname)
$pp->getopt('TIMEOUT');
$pp->shutdown_now
$pp->shutdown_next_time
To install PersistentPerl you will need to either download a binary package for your OS, or compile PersistentPerl from source code. See DOWNLOADING for information on where to obtain the source code and binaries.
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.
To compile PersistentPerl you will need perl 5.004 or later, and a C compiler, preferably the same one that your perl distribution was compiled with. PersistentPerl is known to work under Solaris, Redhat Linux, FreeBSD and OpenBSD. There may be problems with other OSes or earlier versions of Perl. PersistentPerl 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.
To do a standard install from source code, execute the following:
perl Makefile.PL make make test make install
This will install the perperl and perperl_backend binaries in the same directory where perl was installed, and the PersistentPerl.pm module in the standard perl lib directory. It will also attempt to install the mod_persistentperl module if you have the command apxs in your path.
If you don't have permission to install into the standard perl directory, or if you want to install elsewhere, the easiest way is to compile and install your own copy of perl in another location, then use your new version of perl when you run ``perl Makefile.PL''. The PersistentPerl binaries and module will then be installed in the same location as the new version of perl.
If you can't install your own perl, you can take the following steps:
To compile the optional apache mod_persistentperl 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:
LoadModule persistentperl_module modules/mod_persistentperl.so
If you are using Apache-1, also add:
AddModule mod_persistentperl.c
Once mod_persistentperl 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 PersistentPerl are similar to those of regular CGI. If you don't understand the security implications of the changes below then don't make them.
Alias /perperl/ /home/httpd/cgi-bin/ <Location /perperl> SetHandler persistentperl-script Options ExecCGI allow from all </Location>
AddHandler persistentperl-script .perperl <Location /> Options ExecCGI </Location>
Starting in version 1.8.3 an option was added to limit the number of perl backends running. See MaxBackends in Options Available above.
%ENV
and @ARGV
are the only globals changed between requests.
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 persistentperl:
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 perperl will pre-compile your script.
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; }
use Fcntl; fcntl(STDOUT, F_SETFD, FD_CLOEXEC);
This will set the close-on-exec flag on standard out so it is closed when oracle is exec'ed.
The group feature in PersistentPerl can be used to help reduce the amount of memory used by the perl interpreters. When groups are not used (ie when group name is ``none''), each perl script is given its own set of perl interpreters, separate from the perl interpreters used for other scripts. In PersistentPerl each perl interpreter is also a separate system process.
When grouping is used, perl interpreters are put into a group. All perl interpreters in that group can run perl scripts in that same group. What this means is that by putting all your scripts into one group, there could be one perl interpreter running all the perl scripts on your system. This can greatly reduce your memory needs when running lots of different perl scripts.
PersistentPerl group names are entities unto themselves. They are not associated with Unix groups, or with the Group directive in Apache. Group names are created by the person running PersistentPerl based on their needs. There are two special group names ``none'' and ``default''. All other group names are created by the user of PersistentPerl using the Group option described in OPTIONS.
If you want to use the maximum amount of grouping possible (ie all scripts in the same interpreter), then you should always use the group name ``default''. When you do this, you will get the fewest number of perl interpreters possible. Each perl interpreter will be able to run any of your perl scripts.
Although using group ``default'' for all scripts results in the most efficient use of resources, it's not always possible or desirable to do this. You may want to use other group names for the following reasons:
Other scripts may make changes to included packages, etc, that may break other scripts running in the same interpreter. In this case such scripts can be given their own group name (like group name ``pariah'') to keep them away from other scripts that they are incompatible with. The rest of your scripts can then run out of group ``default''. This will ensure that the ``pariah'' scripts won't run within the same interpreter as your other scripts.
Say you have an email application that contains ten perl scripts, and since the common perl code used in this application has a bad memory leak, you want to use a MaxRuns setting of 5 for all of these scripts. You then want all your other scripts to run in a separate group with a normal MaxRuns policy. What you can do is edit the ten email scripts, and at the top, put in the line:
#!/usr/bin/perperl -- -gmail -r5
In the rest of your perl scripts you can use:
#!/usr/bin/perperl -- -g
What this will do is put the ten email scripts into a group of their own (named ``mail'') and give them all the default MaxRuns value of 5. All other scripts will be put into the group named ``default'', and this group will have the normal MaxRuns setting.
Binaries for many OSes can be found at:
http://daemoninc.com/PersistentPerl/download.html
The standard source code distribution can be retrieved from any CPAN mirror or from:
http://daemoninc.com/PersistentPerl/download.html http://www.cpan.org/modules/by-authors/id/H/HO/HORROCKS/
Sam Horrocks http://daemoninc.com sam@daemoninc.com
A lot of people have helped out with code, patches, ideas, resources, etc. I'm sure I'm missing someone here - if so, please drop me an email.
perl(1), httpd(8), apxs(8).
http://daemoninc.com/PersistentPerl/
Please report any bugs or requests for changes to the mailing list.
Copyright (C) 2002 Sam Horrocks
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.
This product includes software developed by the Apache Software Foundation (http://www.apache.org/).