(This msg bounced on me off the webware-discuss list... sent 9/7)
OK, I understand what you're talking about now. My thought is that it's a
generally good idea, but that we wouldn't necessarily scrap the adapters
right away. For one thing, FastCGI wasn't supported on Windows at one point
and currently I don't know if it is and if so if it's beta and production
Of course, I could check right now, but my other point is that there's no
reason we couldn't beef up the app servers with a FastCGIServer mix-in
class and try all this out while the adapters sit where they're at.
If FastCGI works out nice, I could certainly deal with axing the adapters,
unless someone can point out a problem here.
Dan, did you wanna take a crack at creating the FastCGIServer mix-in class?
At 11:07 AM 9/7/00 -0400, Dan Green wrote:
> > Wouldn't a mod_python adapter that was resident in Apache and talked
> > directly to the app server be faster than launching a CGI on every request
> > that talks to the FastCGI adapter that talks to the app server?
> > I don't have anything against your idea of using this bridge; I think it's
> > good, but I also think it's likely that we'll have more than one adapter in
> > order to squeeze more speed from the situation...
> > -Chuck
>What I meant was to convert ThreadedAppServer and AsyncThreadedAppServer to
>accept FCGI requests instead of Webware Adaptor requests. If we do away with
>the adaptor stuff entirely, and just use FastCGI, we get a number of
>1. FastCGI is maintained by a good group of guys that concentrate on it.
>2. Launching the CGI version of FastCGI (written in C) is a lot less costly
> than launching WebKit.cgi (written in Python).
>3. We no longer have to worry about the protocol.
>So I'm not actually talking about a FastCGI server between the web server and
>Webware, I'm talking about porting Webware to being implemented purely as a
>FastCGI server, letting us worry about building a kick-ass Appserver and
>letting the FastCGI guys worry about a neat-o module for different web
>Are there any advantages the adaptors provide that FastCGI does not?
>Either way, we're cutting out the middleman of the adaptors. In the case of
>FCGIAdaptor, the setup looks like this:
>Apache -> mod_fcgi -> FCGIAdaptor -> Webware
>When it could look like:
>Webserver -> (mod_fcgi or cgi-fcgi) -> Webware
>As a dirty test, this is the worst result I got from "time cgi-fcgi":
>0.000u 0.021s 0:00.01 200.0% 0+0k 0+0io 0pf+0w
>and the worst result I got from "time WebKit.cgi":
>0.198u 0.110s 0:00.78 38.4% 0+0k 47+17io 2pf+0w
>So already, FastCGI is beating the pants off us in CGI mode just by virtue of
>not having to load a new Python interpreter at each request.