So to avoid confusion (and to get a kewl domain name), I've renamed the CGI server to "CRINOID". It still has multiple arms :-)
Perl was fast enough to do the calculations I needed (showing distortion of a neutrino energy spectrum caused by oscillations), and display the results in a nice graph, but it was the startup time that was the killer.
Soon after, I started putting class materials on the Web, and wanted some instructional CGIs...but I *knew* that the students are an impatient bunch and would hit the "stop" button if a script took more than a few seconds to respond.
CRINOID is the result of trying to put fast Perl CGIs on the OSU HTTP server. And while some of my more recent instructional CGIs are slow for computational reasons (like my CGI for tracing light rays around a black hole), much of the startup penalty has been eliminated.
The speed advantage is more noticeable with CGIs that produce GIF output because the graphics package slows down Perl startup. In addition, the extra steps needed for "normal" CGIs to produce GIFs (writing to tempfile, copying to server) are eliminated. An example, here's STARS.PL that produces a random starfield. It's a ".com" file because we have to set up PGPLOT and redirect the output to a temp file that is then copied to the HTTP server for output (STARS.COM source).
With CRINOID, one can run the Perl directly CRINOID STARS.PL without a COM-file wrapper. While there may not seem to be huge speed differences, check the information below about script "reusablity", which gives another appreciable speed increase.
Before this gets too complicated, here's a diagram of the various components that make up CRINOID.
This allows one to "tune" the resource usage and responsivness of the CGIs...scripts that are heavily used can be assigned to a "group" of processes that have different min/max settings than scripts that are lightly used.
CRINOID itself (as opposed to the individual Perl-processes, which I call TENTACLEs) is multi-threaded, so it can respond quickly to requests, sending them off to various TENTACLE processes.
When CRINOID starts up a TENTACLE process, it loads Perl, loads up any modules that are set for "pre-loading" (things like PGPLOT, that are slow to start are good candidates for this) and waits for requests from CRINOID.
CRINOID sends TENTACLE a request with the %ENV data for running the script, TENTACLE pushes the %ENV data into Perl and runs the script, piping its input and output from CRINOID. After the script is run, TENTACLE cleans up and resets, waiting for another request.
If the same script is requested of TENTACLE, it can be simply re-run, saving the compilation time. This is not the default however, because a script that is re-run will already have been initialized. If your script counts on "uninitialized" variables, then it shouldn't be re-run:
if (!defined($x)) { # $x isn't defined first time script is run
...do stuff..
}
$x = 123;
In most cases, such scripts generate "uninitialized variable" complaints when run with $ perl -w. Good coding practice will result in scripts that can be reliably re-run, in which case you just set the variable (inside the script):
$CRINOID::Reuse = 1;
which will flag the script as reusable. For backward compatibility,
the $SQUID::Reuse flag is also accepted.
Remember the STARS.PL script up above? Well, here's the same script (source), only with $CRINOID::Reuse set. You can try it here. Hit "reload" a few times to test responsiveness and compare.
# example OYSTER.CONFIG
#
#
preload PGPLOT
preload Digest::MD5
errlog oyster.log
loglevel 3
The "preloads" are modules to be preloaded when each Tentacle starts up.
The "errlog" and "loglevel" refer to logging that is done by the Oyster
perl wrapper code. See the OYSTER. script for more detail.
The errlog file gives you information about what modules are preloaded and which scripts were run. For example:
Running script phys151 at Thu Dec 9 08:51:31 1999
Preloads: UNIVERSAL DynaLoader Socket Digest::MD5 PGPLOT
Script: /DISK$USERS/LANE/www-cgi phys151/big-bang.cgi
allowing :all
denying exit
To get a look at the sort of CGIs that I've built for use on CRINOID, here's an overview with explanations and links to the CGIs.
I've also used CRINOID to implement a scheme where students can check their scores in some courses I've taught. It gives them a better idea of how they're doing in the course, and catches those annoying (and damn near inevitable) clerical errors when scores are entered. BTW, they aren't looking at the master score file, but a simplified copy that is transfered from a different machine. I've also used CGIs to implement online quizzes.
Information on Perl 5.6.0 is now available.