> 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/
##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################
