Persistent Perl on the Virtual Host

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 programs.

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 it.

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 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.

CAVEATS

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!

Next: Installation

This article originally appeared in the August 31, 2000 edition of the WebReference Update Newsletter.