FastCGI

Encyclopedia : F : FA : FAS : FastCGI

FastCGI is a computer software technology for integrating interactive programs into a web server. FastCGI is a variation on the earlier Common Gateway Interface (CGI); FastCGI's main aim is to lessen the burden on the web server imposed by each individual CGI program, allowing the server to scale up to handle many more concurrent requests.

When handling each request to a CGI program, a traditional webserver will create a new process to handle the request. The CGI program is run in that process, the result sent, and then the process is discarded. Creating processes is a resource-expensive task, and each concurrent process imposes a nontrivial burden on the server. For this reason CGI based webservers under heavy load often experienced significant slowdowns, or became mostly unresponsive.

To address the scalability shortcomings of CGI, a number of software providers produced different schemes for communication between the core webserver and plug-in programs. One such was ecommerce company Open Market, who introduced FastCGI into their webserver product in the mid 1990s.

Instead of creating a new process for every request, FastCGI uses a single persistent process which handles many requests over its lifetime. Processing of multiple requests simultaneously is achieved either by using a multi-threaded responder process, or with non-blocking I/O and an event loop. FastCGI also allows programs to get the web server to do certain simple operations, like reading in a file, before the request is handed over. Environment information and page requests are sent from the web server to the process over a TCP connection (for remote processes) or Unix domain sockets (for local processes), with one connection per request. Responses are returned from the process to the web server over the same connection. The connection is closed at the end of a response, but the web server and the process are left standing.

Although initially developed by Open Market, FastCGI was implemented by a number of other webserver makers. The FastCGI approach, however, competed against other techniques which also aimed to speed and simplify server-subprogram communications, but which didn't follow the CGI paradigm. Apache modules such as mod_perl and mod_php appeared around the same time and seemed to be even better replacements for CGI, allowing closer integration with the core webserver.

FastCGI languished for many years; however, later years have seen a resurgence in interest in FastCGI ^{[[Citing sources citation needed]]}. Many web site administrators and programmers are finding that the separation of web applications from the web server in FastCGI (and the simpler SCGI) has many desirable advantages over embedded interpreters (mod_perl, mod_php, etc.). This separation allows server and application processes to be restarted independently — an important consideration for busy web sites. It also facilitates per-application security policies — important for ISPs and web hosting companies. It is possible to run a separate application process for each user; running with the user's assigned privileges, it can't affect the applications and data of other users.

As a server-neutral standard protocol adopted by newer web servers (such asLighttpd and Zeus), FastCGI has also enabled web application portability; in contrast, applications developed for embedded interpreters (such as mod_python) are often tightly bound to the Apache API. Recent frameworks such as Ruby on Rails, Catalyst, and Django allow use with either the embedded interpreters (mod_ruby, mod_perl, or mod_python respectively) or with FastCGI.

External links

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.