[Web-SIG] Preferred set of WSGI servers

[Ian Bicking]

James Y Knight wrote:
> On Apr 28, 2005, at 2:02 PM, Ian Bicking wrote:
> <What I want in a WSGI server>
> 
> twisted.web2 supports: HTTP, HTTPS, CGI, and I wrote SCGI yesterday and 
> will commit it this weekend. FastCGI looks like a complicated protocol, 
> so it'll probably be a bit harder than SCGI to implement. Is there 
> actually a reason to support it as well as SCGI?

While FastCGI isn't defined as having layers, I'd kind of treat it like 
that.  From what I can tell, it's like SCGI with a stderr stream...? 
Other parts could probably be ignored.  The advantage is that it's more 
widely supported/installed.  I think, kind of.  For example, lighthttpd 
has built-in FastCGI support.  But then I bet it would be easy to 
convince them to include SCGI too.

> Right now, web2 runs WSGI apps in threads. It'd be possible to write a 
> wrapper that runs them in their own processes, too, but would that give 
> any advantage vs the simple CGI->WSGI wrapper that already exists? You 
> can just use web2's ability to run CGIs to run 
> WSGI-in-separate-processes also.

Well, the possible advantages:

* Fork instead of spawn a process, so as to save startup time.  Not 
possible on Windows.
* Reuse processes, so as to save startup time.  Possible on Windows, I 
think.  Though they went through all of that trouble in Apache 2 (and 
even some weird fork of 1.3) to make it threaded, so maybe there's 
something I don't know.

But I feel fuzzy on the details, so maybe some of this is a wash.  Could 
you just run, say, ten non-threaded Twisted servers, and have the main 
server delegate a request via SCGI to one of those subservers?  Is it 
acceptable for a Twisted server to block if you aren't serving 
concurrent requests?  I don't do enough multiprocess programming to 
speak intelligently on some of this.

> It is my desire to enable twisted.web2 to be used to host any 
> application in any environment, by providing a number of different 
> deployment options and app running options.
> 
> I've been developing it somewhat under the radar, but It's getting to 
> the point where it's fairly stable. At this point the major TODO is 
> sitting down and writing some documentation, so I'll try to get an alpha 
> release out soon.

One advantage of WSGI is that you don't need to document it.  You'd 
still have to document server invocation and some other details, but 
lots of things people think of as part of the server needn't be (e.g., 
name-based virtual hosting).  People who plan to do async programming 
under twisted.web2 probably need much more information about the 
internals, but WSGI users only need to know you Do The Right Thing (not 
how you do it).

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org