Discuss mailing list

[Tim Groeneveld <tim AT timgws.com.au>]

If it's a CGI application that is being forked a number of times, it is 
relatively cheap (ie, not resource intensive).

FastCGI is benifitial when launching applications that are written in Python, 
PHP, Ruby etc simply because one cgi application can be used multiple times 
to render multiple pages (ie, you do not need to launch PHP 100 times to 
render 100 pages, only once or twice*)

If it's just a simple CGI binary, it won't matter that much. There are not 
too many libraries involved in a simple C cgi binary.

* this depends on how many pages you are rendering at a time, etc.

----- Original Message -----
> On Mon, Jun 11, 2012 at 2:46 AM, Martin C <martin AT mchomenet.com>
> wrote:
> >> I wouldn't suggest that you use CGI, though. It's old and slow.
> >
> > I tried to google this but only found a few references to people
> > talking
> > about having to load Perl and it's various modules, ...
> 
> From what I've gathered is that there's CGI, then there's Fast CGI.
> It's a slightly different standard that reduces overhead. If I recall
> correctly, CGI runs the CGI program every time it makes a request.
> Fast CGI lets the CGI program keep running (so there's no overhead of
> starting/stopping the program constantly) and sends requests through
> a
> socket. I think it also supports things in a more flexible manner,
> but
> I don't know the details off-hand.
> 
> 
> --------
> You are a member of the OpenNIC Discuss list.
> You may unsubscribe by emailing
> discuss-unsubscribe AT lists.opennicproject.org
>