Editing Common Gateway Interface (section)

== Alternatives ==

For each incoming HTTP request, a Web server creates a new CGI [[process (computing)|process]] for handling it and destroys the CGI process after the HTTP request has been handled. Creating and destroying a process can consume more CPU time and memory resources than the actual work of generating the output of the process, especially when the CGI program still needs to be [[interpret]]ed by a virtual machine. For a high number of HTTP requests, the resulting workload can quickly overwhelm the Web server.

The [[computational overhead]] involved in CGI process creation and destruction can be reduced by the following techniques:

* CGI programs precompiled to [[machine code]], e.g. precompiled from [[C (programming language)|C]] or [[C++]] programs, rather than CGI programs executed by an interpreter, e.g. [[Perl]], [[PHP]] or [[Python (programming language)|Python]] programs.
* Web server extensions such as [[Apache modules]] (e.g. <code>[[mod_perl]]</code>, <code>[[mod_php]]</code> and <code>[[mod_python]]</code><!-- correct spelling, do not change -->), [[Netscape Server Application Programming Interface|NSAPI]] plugins, and [[ISAPI]] plugins which allow long-running application processes handling more than one request and hosted within the Web server.
* [[FastCGI]], [[Simple Common Gateway Interface|SCGI]], and [[Apache JServ Protocol|AJP]] which allow long-running application processes handling more than one request to be hosted externally; i.e., separately from the Web server. Each application process listens on a socket; the Web server handles an HTTP request and sends it via another protocol (FastCGI, SCGI or AJP) to the socket only for dynamic content, while static content is usually handled directly by the Web server. This approach needs fewer application processes so consumes less memory than the Web server extension approach. And unlike converting an application program to a Web server extension, FastCGI, SCGI, and AJP application programs remain independent of the Web server.
* [[Jakarta EE]] runs [[Jakarta Servlet]] applications in a [[Web container]] to serve dynamic content and optionally static content which replaces the overhead of creating and destroying processes with the much lower overhead of creating and destroying [[Thread (computer science)|threads]]. It also exposes the programmer to the library that comes with [[Java Platform, Standard Edition|Java SE]] on which the version of Jakarta EE in use is based.
* Standalone HTTP Server
* [[Web Server Gateway Interface]] (WSGI) is a modern approach written in the [[Python programming language]]. It is defined by PEP 3333<ref>{{cite web |title=PEP 3333 – Python Web Server Gateway Interface v1.0.1 {{!}} peps.python.org |url=https://peps.python.org/pep-3333/ |website=Python Enhancement Proposals (PEPs) |access-date=5 April 2024 |language=en}}</ref> and implemented via various methods like <code>[[mod_wsgi]]</code><!-- correct spelling, do not change --> (Apache module), [[Gunicorn]] web server (in between of Nginx & Scripts/Frameworks like Django), [[UWSGI]], etc.

The optimal configuration for any Web application depends on application-specific details, amount of traffic, and complexity of the transaction; these trade-offs need to be analyzed to determine the best implementation for a given task and time budget. [[Web framework]]s offer an alternative to using CGI scripts to interact with user agents.