[Web-SIG] Preferred set of WSGI servers
ianb at colorstudy.com
Fri Apr 29 20:35:12 CEST 2005
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
More information about the Web-SIG