FastCgi [http://www.fastcgi.com/] is basically an extension of CGI so that the process (external to the main web server) can serve more than a single page, so that the process creation overhead (and latency) are amortized over a large number of connections. The need to create a new process for every single request is a serious limitation on the scalability of CGI. See also the discussion in RunScriptAsDaemon. ---- (2Apr2000) In the grand march forward, FastCgi seems to fallen by the wayside. Various in-process options (ASP, mod_perl, mod_jserv, php) are getting most of the press these days. ''Actually I believe ZopeApplicationServer will support FastCgi. But it supports other variations on the theme too.'' 28 Nov 2002: FastCGI is alive and kicking. Support for Apache 2 is slow in coming, but the mailing list is fairly active (31 msgs in Nov., 81 in Oct., 55 in Sept.). -- TerrelShumway ''I wouldn't be surprised if FastCGI's popularity has picked up again, thanks to frameworks like RubyOnRails supporting it out of the box.'' ---- I think part of the reason FastCgi doesn't get enough press or isn't as popular, is because: *PeopleLikeStandards. PHP is a standard. It's structured on a website. It's one language. Cgi is a standard, but it is not one language like PHP is. CGI doesn't have one manual on it like PHP does. PHP has a manual and a website, simple as that. A standard with a structure. CGI probably has 50,000 websites describing it and no structure at all. It's so general and useful that people miss the point of CGI since it isn't PeopleLikeStandards compliant. *There is no basic CGI scripting language to use.. if you want to set up CGI you first have to know what CGI is.. and a lot of people think "CGI is perl" or "this is too much work, PHP will be easy to set up". *or they think CGI slow and ineffecient because it opens up one process for each user. But in fact with PHP, ASP, Perl, etc., the interpretting is quite a similar situation. It's just like opening up a new process, since all html needs to be sent to an interpretter each time someone opens a web page. Just like opening a new process. *or they think that CGI is slow and ineffecient because they've heard stories and rumors, but they haven't actually done their own research or looked at benchmarks/examples. *All the benchmarks say that regular old CGI is faster than PHP and ASP. So what about FastCgi. Yet, people continually walk around saying that CGI is ineffecient. Since when was interpretting code with all sorts of HTML inbetween effecient? So here we have FastCGI which is even more effecient than the already effecient CGI. --Lars Olson ---- SCGI (http://www.mems-exchange.org/software/scgi/) is an alternative that is supposed to be easier to implement. -- TerrelShumway WSGI (WebServerGatewayInterface) is an interface between a WebServer and a WebFramework for PythonLanguage. Used by DjangoProject and Pylons, among many others. -- RobertField