[Web-SIG] WSGI diagram

[Cliff Wells]

On Tue, 2007-08-21 at 08:33 +1000, Graham Dumpleton wrote:
> On 21/08/07, Cliff Wells <cliff at develix.com> wrote:
> > Hi,
> >
> > There's someone working on a mod_wsgi module for the Nginx HTTP
> > server/proxy and Nginx's author was asking if there is a diagram
> > somewhere outlining the WSGI protocol (I think perhaps he'd help if he
> > understood WSGI).  I google'd a bit but came up empty-handed.
> >

> Some will no doubt say I am biased and trying to protect my turf, but
> from what I understand of the aims of Nginx HTTP, in as much as it is
> trying to create the fastest web server around, embedding a Python
> interpreter within the main server processes would work against that.
> This is because supporting Python in an embedded manner may impact
> performance in serving static files etc.

The author of the module says the recommended deployment method will be
running a second Nginx server dedicated to the WSGI process and proxy to
that with a main Nginx server, probably for this very reason.

Personally I think he'd do better implementing a mod_ajp and then
utilizing the ajp-wsgi [1] server since this would probably be easier to
implement and I suspect ajp-wsgi has a smaller footprint than Nginx
(even though Nginx is pretty small), but it's not my project =)

> Thus, it may make more sense to be suggesting people use the existing
> FASTCGI support in Nginx HTTP for hosting Python WSGI applications.
> That way you aren't necessarily burdening the main server processes
> with the extra overhead. 

Lots of people do this or proxy to a Python HTTP server.  I think the
idea is to get rid of one layer of relatively inefficient processing (a
HTTP server in Python) by doing it in C.  How much performance impact
this will actually have in real world applications I don't know
(although Apache's mod_wsgi should give a clue, if there were any
benchmarks published).

> The same argument applies to lighttpd as
> well. As to Apache, many have the opinion that it is getting quite
> bloated anyway, so adding more stuff into the main server processes
> doesn't seem to worry people as much. It does though need to be used
> appropriately though.

Since it's a module, I don't think it will worry people too much ;-)
Nginx has plenty of optional stuff already.  The people who need or want
it will use it, everyone else will skip it. 

> Also note that WSGI isn't a wire protocol like FASTCGI is. It is more
> an programmatic interface definition for adapting a Python application
> on top of a specific web server.  If you specifically want to run WSGI
> applications in a separate daemon process, then you would need to come
> up with your own wire protocol for communicating between the main
> server processes and the daemon process. The daemon mode of the Apache
> mod_wsgi does this, but since this is what FASTCGI defines anyway,
> that is why it may make more sense to use the existing FASTCGI support
> in Nginx HTTP and not bother with a separate module. 

Except that this still requires a fcgi->wsgi gateway that would probably
be just as complicated as direct WSGI support (or done inefficiently in
Python, such as flup).

> In Apache
> mod_wsgi, a new FASTCGI like daemon mode was specifically implemented
> to try and come up with an improvement over the sometimes hard to
> configure and get working FASTCGI implementations for Apache.

Personally, I think FastCGI is too difficult on every server and that
may be another motivation for the author.

> BTW, I hope you would call it something other than mod_wsgi so as not
> to cause confusion with the Apache implementation.

Again, I'm not the author, but I'll bring this up.  However, I'm not
certain it would be any worse than the plethora of mod_fcgi's or
mod_proxy's or mod_xxx's in existing webservers.

Regards,
Cliff

[1] http://www.saddi.com/software/news/archives/49-ajp-wsgi.html