FastCGI if an optimized variation of the normal CGI protocol, which differs primarily in that the application server instances persist across many requests, rather than having to be launched and terminated for each request. FastCGI thus vastly reduces the overhead of servicing web requests, particularly for relatively large/complex application servers (like A-Shell).
FastCGI is widely available on common web servers such as Apache and IIS, but almost certainly requires some configuration to enable. As of this writing, is has only been tested with Apache 2.4 under Windows.
To enable support for FastCGI protocol in A-Shell, change the -cgi command line switch to -fastcgi. A-Shell will then determine whether the server is using FastCGI or normal CGI protocol, and will act accordingly—i.e. support either protocol.
Existing A-Shell CGI applications require a minor modification after which they can support either mode as well, without having to be aware of the difference. Since the main objective of FastCGI is to avoid the need to launch a new instance of the application server for each request, you need to introduce a loop into your application so that after servicing a request, instead of exiting, it loops back to wait for another request. In other words, you must convert this:
<process request>
<send response>
end
to this:
do
xcall CGIUTL, CGIOP_GETREQ, status
if status < 0 exit
<process request>
<send response>
loop
end
The CGIUTL opcode CGIOP_GETREQ waits until the request has been received and is ready to process in the normal way. For the first request after the instance has been launched, it will return immediately (be essentially a NOP). For subsequent requests, it waits until another client submits a request, or perhaps the server shuts us down. In the case of normal CGI mode, the second request will return -1, telling the app to shut down, as it would normally do for CGI.
Note that FastCGI does not eliminate the standard CGI problem of having to reestablish the client context for each request. Consecutive requests received by the server instance of your application can easily be from different clients, so you need to design some means of identifying the client and saving/restoring the context of that client's browser session—using parameters passed with each request or cookies, saved context files on the server, etc.
