No matter how optimized your hardware and operating system are, it is easy to get truly awful performance with a badly written CGI. There may be no constraint on how long a CGI is allowed to run, so if your CGI is ill-mannered or overloaded, the user will suffer.
We should distinguish here between merely inefficient CGIs, infinite loops, and runaways. Coding for efficiency is a huge topic and is highly language-dependent. We cover efficiency in Section 20.5, later in this chapter.
If your CGI somehow gets into an infinite loop, the web server may well wait forever for the CGI to return results. This, in turn, means that the user will probably be left staring at a blank or partially filled browser for quite some time. Or worse, they’ll just hit the Back button and then try again, putting another infinitely long CGI in motion on your server, and thus using up CPU time that produces nothing. CGI programs don’t know when the user hits the Stop button on the browser. The program often finds out only when it tries to output HTML and receives a SIGPIPE signal because the socket is no longer valid, but this may depend on the configuration of the operating system and web server.
To kill an infinitely looping CGI, you must first find its process ID (PID). The classic way to do this is with the Unix ps command. The options to ps vary with the version of Unix. Under Solaris, for example, you can list all of your ...