Figure 1.2 shows a time line for the execution of a CGI POST request using
the data obtained from the experiments. 
These results show that the minimum time to handle a CGI POST request using HTTP 1.0 on a PA RISC machine should be about 80 milliseconds for the CERN HTTP Server. (I am ignoring the 120 milliseconds for which the server seems to block on a socket - see later.) This includes:
The headers sent with the request are just about the minimum you would get (see section 1.2.3). A typical browser will include many more headers, as it will be able cope with many more media types. So the time of 43 milliseconds will almost certainly be exceeded in practice. This is a CPU bound activity (no blocking on i/o), so using threads will not help to lower this overhead.
Of the remaining 23 milliseconds, 7 milliseconds are taken by the CGI program to url-decode the data and format the results (this will be more if more data is sent in the request). I speculate that most of the remaining 16 milliseconds are spent by the client preparing the request (e.g. url-encoding the data), parsing the reply headers and setting up the TCP connection. (Setting up the TCP connection will almost certainly take longer and extend this time in a wide-area network.)
These results show that for high performance, better encoding of HTTP header information is needed. ASCII headers are great for debugging, but make for inefficient parsing. (I understand the developers of HTTPng are considering a binary encoding for headers.)
Although the fork/exec model of execution enforces stateless interaction, higher performance would be achieved by having a threaded server in which a lightweight thread serviced each request, rather than a separate process. Also instead of using CGI to extend the functionality of the server and gateway to other applications, it would be better to define extension HTTP methods. In this model, the server could send an HTML form which invoked an extension HTTP method rather than overloading GET and POST to launch a CGI program. The extension HTTP method would be executed as a thread inside the server.
I am unable to explain why the server "hangs" for 122 milliseconds to read in 542 bytes of data which have almost certainly arrived at the socket. So the quoted minimum time of 80 milliseconds is arrived at by subtracting 122 milliseconds from the measured minimum time of 202 milliseconds.
In summary, the experiments show conclusively that HTTP server execution could be made more efficient by using better header encoding for HTTP. In addition, a gateway to third party applications would be more efficient by incorporating it into the HTTP server as an HTTP extension method. Lightweight threads should be use to handle requests, rather than forking a new process to handle each request. Taken together, this would significantly improve the performance of the heavily loaded, commercial HTTP server.
I would like to acknowledge the helpful comments of the following members of the ANSA team: Mike Beasley, Andrew Herbert, Mark Madsen, Ashley McClenaghan and Owen Rees.
[EDWARDS 95] "A Stub Compiler for CGI and HTTP: The Programmer's Guide", APM.1465.00.02 , Nigel Edwards, APM Ltd., Cambridge U.K., May 1995.
Nigel Edwards <nje@ansa.co.uk>, Owen Rees <rtor@ansa.co.uk>