[cgiapp] Re: The benefits of vanilla CGI vs. FastCGI

[Mark Stosberg]

> 1. Provide a link to, or better yet, include the number from your
> recent web framework benchmarking;

Thanks, I'll consider adding that. 

> 2. Each of the examples you have provided where vanilla cgi might make
> a lot of sense are, in my view, ridiculously low powered. My
> off-the-cuff reaction would be that vanilla cgi is suitable for,
> perhaps, even much much more high use/traffic/load applications. Would
> be nice to get some kind of numbers... "cgi use is perfectly ok for
> upto 10,000 requests per day applications" or "100 requests per
> minute" kind of numbers. That would give a better, and perhaps more
> realistic sense of cgi's robustness, particularly under load.

This ia good a point. I suppose I didn't want to push the boundary where
people would start to argue that persistence would be a win. 

Without doing a fancy benchmark, the initial benchmarks I published
recently do give you an idea of how far you can scale with vanilla CGI.
If you can return a result in under a second, then therefore you can 
accomodate 1 request per second with a single web-server process. And 
if you have the memory and CPU power, you can serve several CGI requests
per second. But 1 request / per second seems fairly clearly possible,
And that is a *lot* of traffic for many applications. 

> 3. Finally, maybe it is time to re-christen CGI::Application to
> Web::Application.

We had discussed renaming before, and that's part of where Titanium came
from. At this point my interest in renaming CGI::Application itself as
waned, but I could be swayed.   

Now FastCGI is gaining mindshare so at least the "CGI" acronym is still
in wider use, even if vanilla CGI has been going through a stage of
getting a bad rap.

    Mark

-- 
http://mark.stosberg.com/