More about Perl and CGIplus/RTE

Perl is a powerful language and should be used to greater advantage. Unfortunately in a CGI context the overheads of starting Perl (particularly under VMS) can severly impact request response time and system overhead.

WASD's persistant scripting (CGIplus) and persistant Run-Time Environment (RTE) both improve script response time and reduce system impact by allowing scripting resources to be loaded into a process just once before processing multiple requests. For detailed information on CGIplus and RTE see WASD Scripting Environment. Just compare the latency difference between the CGI, CGIplus and RTE usage (after the first access) of exactly the same script in examples provided in the following two sections.

Perl RTE

> scripts: | PerlRTE_example1.pl PerlRTE_example2.pl PerlRTE_example3.pl
> CGI: | /plbin/PerlRTE_example1 /plbin/PerlRTE_example2 /plbin/PerlRTE_example3
> RTE: | /plrte/PerlRTE_example1 [restart RTE] /plrte/PerlRTE_example2 /plrte/PerlRTE_example3

> Notes:

> 1. Due to significant variations between VMS Perl versions the PerlRTE.c executable may have to be purpose-built for any given site.

> 2. These demonstrations require two special mapping rules included in the default HTTPD$MAP but may be absent on existing sites after an update.

>          exec /plbin/* /ht_root/src/perl/*
>          exec /plrte/* (cgi-bin:[000000]perlrte.exe)/ht_root/src/perl/*

Benchmarking the PerlRTE_example3.pl script (which loads CGI.PM) using ApacheBench on the author's development system indicated 0.45 and 10 requests/second for the CGI and RTE usages respectively. Expressed another way, the RTE usage responded 25 times faster!! Remember this is the same script - no changes apart from invocation path.

The Perl Run-Time Environment should execute any standard Perl script using any collection of modules. This approach uses methods and code described in the 'perlembed' document "Maintaining a persistent interpreter" section, to load and keep cached multiple script and module sources. I am currently unsure of exactly how isolated each script loaded really is. Each is treated as an autonomous package and so storage restrictions etc. need to be observed. However apart from that it would seem as if any old (perhaps slightly tweaked) CGI script could be used within this environment.

The CGI environment variables are available via the %ENV associative array. There are a number of ways to customize the startup of this environment. See the PerlRTE.c and PerlRTeng.c sources for detailed information.

CGIplus Perl

> script: | CGIplusPM_example1.pl
> CGI: | /cgi-bin/CGIplusPM_example1
> CGIplus: | /cgiplus-bin/CGIplusPM_example1 [restart]

Benchmarking this using ApacheBench on the author's development system indicated 0.3 and 6.9 requests/second for the CGI and CGIplus usages respectively. Expressed another way, the CGIplus usage responded 20 times faster! Remember this is the same script - no changes apart from invocation path.

### CGIplus.pm

The CGIplus.pm Perl module is intended to assist script authors write scripts that may be used transparently in both vanilla CGI environments (including non-WASD) as well as under WASD CGIplus. The only essential difference between CGI and CGIplus is the mechanism for deriving the CGI variables, everything else is exactly the same as plain-old CGI.

The module also compensates for variations in VMS environments. Most VMS CGI environments provide their CGI variables via DCL symbols. Many Perl scripts access these via the %ENV array. Some VMS Perl versions do not support DCL symbols via this mechanism. CGIplus.pm detects whether CGI variables are available via %ENV and if not attempts to use Charles Bailey's VMS::DCLsym extension module built into most versions of VMS Perl.

In summary the module transparently makes CGI variables available for most VMS Perl CGI environments, as well as for WASD's persistant CGIplus.

### Binary Responses

VMS' RMS complicates output streams under Perl. This is a particular issue with CGIplus end-of-file sentinals, which must be output as a single record. CGIplus.pm attempts to provide a simple mechanism for providing binary streams if necessary, while still ensuring it's own records are not interfered with. This uses Charles Bailey's VMS::Stdio extension module built into most versions of VMS Perl.

This script demonstrates how the modules stream functions can be directly used.

> script: | CGIplusPM_example2.pl
> CGI: | /cgi-bin/CGIplusPM_example2
> CGIplus: | /cgiplus-bin/CGIplusPM_example2 [restart]

This script demonstrates how to simply return a binary file as a response.

> script: | CGIplusPM_example3.pl
> CGI: | /cgi-bin/CGIplusPM_example3
> CGIplus: | /cgiplus-bin/CGIplusPM_example3 [restart]

Any accessable image location may be added to these scripts following the script part. Again, because these are being accessed via a CGIplus script, notice the difference in latency between the initial and subsequent requests.

- /cgiplus-bin/CGIplusPM_example3/ht_root/runtime/httpd/app.gif
- /cgiplus-bin/CGIplusPM_example3/ht_root/runtime/httpd/directory.gif
- /cgiplus-bin/CGIplusPM_example3/ht_root/runtime/httpd/text.gif
- /cgiplus-bin/CGIplusPM_example3/ht_root/runtime/httpd/preview.gif

Last Revised July 2000