[Web-SIG] WSGI and async Servers

[Graham Dumpleton]

2009/9/18 Armin Ronacher <armin.ronacher at active-4.com>:
> Hi,
>
> For this topic I would love to remember everybody that the web is
> currently changing and will even more change in the future which will
> probably also mean that a lot of what we're doing currently might not be
> common practise in the near future.
>
> WSGI is currently not doing to well for asyncronous applications, so
> people claim.  I don't know where this is coming from, probably because
> everybody still thinks our data storages are traditional databases.  But
> we really have to wake up from that idea and start at least
> *considering* asynchronous designs when it comes to WSGI.
>
> Tornado appeared recently and from a technical perspective, it's a step
> backwards.  It's not supporting all of HTTP and it's clearly not
> supporting WSGI in any way beyond the very basics.  But the interesting
> point is, that this does not matter for many applications.  Even for an
> application that was never designed to be non-blocking that just
> recently dropped MySQL for most of the data, Tornado is a huge
> performance improvement (personal experience).
>
> Why would it be good to encourage async applications on top of WSGI?
> Because people would otherwise come up with their own implementations
> that are incompatible to each other.  Maybe that should not go into WSGI
> but a AWSGI or whatever, but I'm pretty sure we should at least consider
> it and ask people that use asynchronous applications/servers what the
> issues with WSGI are.

Let me clearly state that I am not against the concept of asynchronous
or event driven systems. In my 20+ years of coding I have done more
work in the area of event driven systems than in other areas. My work
on Apache/mod_wsgi and mod_python before that are merely hobbies in
comparison. My bread and butter has been distributed messaging and
publish/subscribe systems based on event driven systems running across
large networks of hosts and sites for building complex real time
applications.

What I simply don't want is for the asynchronous issue to stop us
again from sorting out the synchronous WSGI specification. Let us just
deal with it later rather than it once again becoming a distraction.

FWIW, one thing I am against with event driven systems is those which
are poorly implemented. I also get annoyed when people make claims for
event driven systems that are somewhat tenuous. Although event driven
systems can be good for some things, they have to be used properly.
Trying to adapt them in ways they shouldn't can cause subtle problems.
Often people pushing event driven systems either don't understand the
potential problems, or want to gloss over them in some way. Trying to
bolt a synchronous WSGI directly on top an event driven systems,
particular in a multi process web server is a good example for
potential problems as I have blogged about in the past in relation to
nginx/mod_wsgi. You will get the same sort of potential issues with
Tornado depending on how they try to use it in conjunction with WSGI.

If we ever actually finalise synchronous WSGI and I can get some
measure of closure on Apache/mod_wsgi in as much as it being as
feature complete as worth pursuing, then an event driven based web
serving mechanism for Python applications and associated static files
is certainly an area I am interested in looking at. I already have my
own ideas for how I would go about doing it and it isn't like what
people are doing now. With the sort of mix of technologies I have in
mind I see no reason why it wouldn't perform better than the systems
being pushed in the Python world at present. So, hurry up and work out
this synchronous stuff and maybe I can get back on to the event driven
system, which frankly I find more interesting anyway. :-)

Graham