No matter how optimized your hardware and operating system are, it is easy to get truly awful performance with a badly written CGI. There is 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 will cover efficiency in the section “CGI Language—Specific Optimization Tips,” 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 if and 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
ps command. Under Solaris, for example, you can list all of your processes ...