Want to speed up your Apache delivery but don't want to go the route of mod_perl or PHP? CGI::SpeedyCGI is just what the doctor ordered to get your scripts running approximately 16 times faster than normal. It
can be installed using the PREFIX tag in the Makefile command on virtual hosts.
This article originally appeared in WebReference.
One of the big problems with the Perl programming language is that
when executed there is a lag in performance due to the actual perl
interpreter starting up. In addition, each process starts another
instance of the interpreter to handle the request. This fact has
long been known and many programs have been created to keep the
perl interpreter in memory, thereby avoid the startup costs, and
letting the script run at speeds that rival C and C++ programs.
The two most popular programs are mod_perl and FastCGI. Both are
free so why isn't the average Web site owner using one of them?
One reason might be that both programs have hooks into the Web
server and running a bad application has the potential to bring
down the Web server. Most hosting companies will not let that
happen so they will not allow their users to access these
So what can all of us folks do that are running our Web sites on
30 mb of space on someone else's server? As long as you have
telnet access to your domain there is something you can do about
CGI::SpeedyCGI written by Sam Horrocks is just what the doctor
ordered to get your scripts running approximately 16 times faster
than normal. It can be installed using the PREFIX tag in the
Makefile command on virtual hosts. The installation of this module
to a virtual host is different than installing a standard module
so be sure to read the installation instructions closely.
How it works
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 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
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.
1. To run any persistent process with Perl the scripts need to be
correctly scoped. Lexical scoping prevents variables from piling
up on each other by releasing the memory back to the server. Since
the process is persistent, a variable that is global will just
concatenate on itself each time the script is run. To combat this
problem, programs must declare variables using "my." This means
that not every script on the Web will run persistently. If the
script does not have "use strict;" written somewhere near the top,
then it is probably not scoped and should not be run persistently.
For a complete definition of scoping, visit www.plover.com/~mjd/perl/FAQs/Namespaces.html.
2. When you run Speedy on a virtual host, Speedy forks off another
version of itself for each user so it isn't advisable that you run
every script with it. Speedy has a time-out variable that can be
set on each script that will keep the Speedy process running even
if the user quits using the script. If you set this time-out to
600 seconds it takes that long for the process to stop. This can
cause problems for the server if you suddenly have a lot of
Speedy processes that are sitting there waiting to quit. Under
heavy load you may run out of sockets since they hang around in a
TIME_WAIT state after closing. Most servers are set up to handle
at least 256 users so it shouldn't be a problem as long as you
keep your time-outs at around 60 seconds.
If you have root access and are running the Apache Web server then
this is no problem because Speedy also comes with mod_speedy,
which keeps the program from forking another process for each
request. You can't install mod_speedy without root access though.
By the way, mod_speedy doesn't hook into the Apache Web server the
way mod_perl and FastCGI do so it's a very safe way for Web farms
to implement persistence on their servers!
To install SpeedyCGI on a virtual host takes a little extra work
than a standard module, but it's worth it. The first thing you
need to do is download the module from search.cpan.org,
then unpack it into a directory on your host. For those not
familiar with how to do this, here's a step by step guide.
To unpack and install type the following commands at the telnet
prompt: (SpeedyCGI can't be installed on NT so don't waste your
tar -xvf CGI-SpeedyCGI-1.8.3.tar
perl Makefile.PL PREFIX=/home/domain (full path to your domain)
Now here's the trick to get it to install because it will always
fail in it's default state. Depending on your path to perl this
might be a little different, but it will be easy to spot if the
make install fails.
Create a "bin" directory in your domain: /home/domain/bin
With Perl located in /usr/local/bin/ you may have to create the
directory /home/domain/local/bin. It appears that Speedy is trying
to emulate where Perl is installed on the server. If you get an
error and it complains about not being able to find the directory
then this is most likely the problem and you can simply create
the required directory and run make install again.
Once that directory is created, go back into the SpeedyCGI
directory and type:
If all goes well you will now have Speedy installed. The shebang
line will be a little different than what you're used to, though.
The following line reflects that you are running the Speedy
executable in your own domain space.
#!/home/domain/bin/speedy -w -- -t60
SpeedyCGI command line options will always follow the -- on the
shebang line. Any options before the -- are perl options. The
above line reflects a time-out of 60 seconds. There are some
other useful options so you should refer to the documentation to
get a thorough understanding of Speedy commands.
About the author:
Mark Porter is a Perl Monger and has been programming perl for
about three years. He currently owns his own business, imChat
Inc which is merging with another business,
Balsa-Tech Inc. They sell business
intelligence software, do custom CGI programming and are currently
looking for startup capitol. Contact Mark at firstname.lastname@example.org.