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

[P Kishor]

On 11/23/08, Mark Stosberg <mark at summersault.com> wrote:
>
>  > 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.

I thought that was the very point of the exercise... at least in my
view, discovering that boundary is very important. That way, as long
as my applications are below that boundary (whatever that might be), I
can safely implement and deploy a vanilla CGI app enjoying is
simplicity and rapid development without worrying about it getting
overwhelmed that big scary persistence frameworks need to be brought
in.

>
>  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.
>

 Just exploring that benchmark more with more realistic applications
might be more useful. Also, a per hour number might be more meaningful
because it accounts better for concurrent requests and other
performance flattening factors as by itself, 1 request/sec is great,
but it may not be linear... it may not mean 3600 requests/hour, but if
the app still returns 1000 requests an hour it may still be more than
adequate for my use. Or, how does a specific request perform when 1000
people are hitting the server concurrently...?


>
>  > 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.

I am not conversant with the politics of CPAN app naming or renaming,
but Web::Application really resonates with me. It describes what I am
really doing... making a web application. Titanium is actually
confusing to me because under the hood I already have a bunch of its
components installed. Now I am not sure if I need to get specific
versions, or if any non-Titanium plugin is going to void my
warranty... and so on. In other words, while a renaming, it is not a
clear, clean renaming.

Consider this an attempt to sway you to consider renaming.

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


-- 
Puneet Kishor http://punkish.eidesis.org/
Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/
Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/