17.1 Issues

The basic CGI protocol simply specifies a way for the Web server and the CGI process to communicate; it doesn't say anything about whether that communication is fast or slow.

What makes script processes fast or slow? Assume for the moment that the script program is written efficiently, and the server has enough resources (CPU, memory) to run it without excessive paging to disk or having the process spend too much time on the computable queue waiting for other processes to finish their quantum of computation time. (These are big assumptions, but they're beyond the control of Web server authors.)

High-performance CGI options generally boil down to (a) ways to use the minimum number of different processes to minimize process creation overhead, (b) ways to minimize the number of image activations, generally by creating persistent scripting environments that don't have to be reloaded for each script, and (c) ways to communicate with the Web server faster than the default.

Process creation is a fairly expensive operation on VMS at least compared with UNIX, where forking a process is pretty cheap. (To be precise to a fault, process creation on VMS isn't all that big a deal, but populating the symbol and logical name tables for the process can be relatively expensive. If it has to run a LOGIN.COM, there's disk access and file parsing time; if it's a subprocess inheriting the environment of its parent, all that information gets transferred through a mailbox, and that is slow.) One general...