There are several drawbacks to mod_cgi that triggered the development of improved web technologies. The first problem lies in the fact that a new process is forked and a new Perl interpreter is loaded for each CGI script invocation. This has several implications:

  • It adds the overhead of forking, although this is almost insignificant on modern Unix systems.

  • Loading the Perl interpreter adds significant overhead to server response times.

  • The script's source code and the modules that it uses need to be loaded into memory and compiled each time from scratch. This adds even more overhead to response times.

  • Process termination on the script's completion makes it impossible to create persistent variables, which in turn prevents the establishment of persistent database connections and in-memory databases.

  • Starting a new interpreter removes the benefit of memory sharing that could be obtained by preloading code modules at server startup. Also, database connections can't be pre-opened at server startup.

Another drawback is limited functionality: mod_cgi allows developers to write only content handlers within CGI scripts. If you need to access the much broader core functionality Apache provides, such as authentication or URL rewriting, you must resort to third-party Apache modules written in C, which sometimes make the production server environment somewhat cumbersome. More components require more administration work to keep the server in a healthy state.