Server Script: Can They Keep Up?
By Lincoln D. Stein
Ever since a Web-indexing robot became trapped in my site's cgi-bin directory and brought the system to a standstill (see "Webmaster's Domain," Web Techniques, October '96), I've been searching for ways to speed up my CGI scripts. This has forced me to look hard at the CGI protocol itself. CGI, the Common Gateway Interface, was designed at a time when Web sites consisted of mostly static files. In those days, server scripts were used as a bit of seasoning to liven up the stew: a feedback form here, a guest book there, and (cool!) a link that even fetches the current time and weather.
More and more, though, server scripts have become Web sites' meat and potatoes. They're everywhere: writing dynamic welcome pages, choosing random messages and pictures to display, generating graphs, and running shopping carts and site-wide text searches. Some organizations have even crossed the Rubicon and are now sporting sites powered entirely by scripts. When a browser requests a URL from one of these sites, a script constructs the appropriate page entirely on the fly from the contents of some database.
All this has made the Web fun and interesting, but it's starting to push at the limits of the CGI protocol. The fundamental problem is that a whole new CGI process is launched every time its URL is called. The operating system has to read the executable script from disk, initialize its memory space, load any dynamically linked libraries it needs, and start it running.
