If your web site is a low volume site, you may not been too concerned about system performance. If your cgi program receive one web hit every 5 seconds, that translates into 5760 over an 8 hour period. For a personal site or many in-house intranet sites, that is a fairly high hit rate. (This figure does not include page requests for static pages)
If you are writing CGIs for a higher volume site, or if you may have to handle more intense peak loads over a short period of time, then performance can be a bigger concern.
Each CGI program that is invoked requires that the web server spawn off a new process. This process runs the Perl interpreter, which parses your code and runs it. This latency and process start-up overhead is the main performance drawback of CGI programs.
Ensuring that your web server has adequate physical memory can help make sure that it can cache frequently used files such as the Perl interpreter and your CGI source code. For servers with rapid arrival rates of CGI requests, having a multi-cpu system may be more beneficial than having a faster single CPU. Multi processor machines can handle multiple simultaneous requests with less process context switching over head than a single CPU machine would be able to.
Finally, if you have a truly high volume site, there are some other options using Perl modules:
Fast cgi scripts are implemented using the CGI::Fast perl module. Rather than starting up a process each time you run a CGI program, Fast CGI pre-allocates a pool of daemons that run a given program. Then rather than setting up the environment variables and spawning off a new process, it sends the data to one of the existing daemons via a socket call. the daemon runs the CGI, returns the output, and continues running waiting for new requests. Because the daemon keeps running, it can maintain state between invocations. This state maintenance can be a good thing or a bad thing. It is good in that you can use this feature to your advantage in some applications. It can be bad in that you need to be more careful about initializing and re-initializing variables. Each daemon only runs one particular script.
Mod perl uses an Apache module that allows each httpd child process to execute CGI script in the same process, rather than spawning off a new process. This dramatically speeds up CGI execution, but does increase the memory demands for each httpd process. Since each httpd process has Perl embedded in it, each httpd child process can run any CGI perl script. Using mod_perl does not necessarily require different coding for your CGI programs, but because the the scripts run inside the httpd daemons, you need to take more care in coding. You need to make a point of closing file descriptors, clearing file locks, initializing variables, and avoiding memory leaks.
Both Fast CGI and mod_perl are said to speed up CGI execution from as much as 10 to 30 times. So while CGI programs may require more care when using these methods, they can be an important tool.
Copyright 2001 - Andy Welter