CGI has maybe the worst lift cycle possible.As designed, each request to a CGI resource creates a new process on the server and passes information to the process via standard input and environment variables.

　　Even with poor performance by today’s standards, CGI was a revolutionary step in the evolution of server-side programming. Developers had across platform method of creating dynamic content using most any of theirfavorite scripting and programming languages. Figure 1-2 shows the improved implementation of CGI. Instead of one requestper a process, a pool of processes is kept that continuously handle requests. Ifone process finishes handling a request, it is kept and used to manage the nextincoming request rather than start a new process for each request.

　　This same pooling design can still be found in many of today’s CGI imple-mentations. Using pooling techniques, CGI is a viable solution for creatingdynamic content with a Web server, but it is still not without problems. Mostnotable is the difficulty in sharing resources such as a common logging utility orserver-side object between different requests. Solving these problems involvesusing creative fixes that work with the specific CGI and are custom-made forindividual projects. For serious Web applications, a better solution, preferablyone that addresses the problems of CGI, was required.