WSGI and async Servers

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

WSGI and async Servers

Armin Ronacher
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.


Regards,
Armin
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and async Servers

exarkun
On 04:40 pm, [hidden email] wrote:

>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.

At PyCon, there was some discussion about what changes could be made to
the WSGI spec to extend it to support asynchronous applications.  I
probably have some notes, and I think I even sent them to the list at
the time.  Perhaps those with an interest in async WSGI could take a
look at those and weigh in on the merits of the conclusions reached.

A number of other people also posted to a thread which covered more of
the WSGI ideas discussed at PyCon.  The top of that thread is here:

  http://www.mail-archive.com/web-sig@.../msg02569.html

I posted an example of what an asynchronous WSGI application might look
like here:

  http://www.mail-archive.com/web-sig@.../msg02582.html

(it looks like I forgot to do anything relating to start_response there
- I don't remember if this was intentional or not).

I think there was also some talk about how it would be desirable to
support asynchronous response header generation.

Jean-Paul
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and async Servers

ianb
In reply to this post by Armin Ronacher
On Thu, Sep 17, 2009 at 11:40 AM, Armin Ronacher
<[hidden email]> wrote:
> 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.

I think AWSGI would be most appropriate.  There's too much going on,
and trying to keep WSGI sane while allowing async is just too hard.
If we fork, then people can get something that really works well, they
can try it out with real applications, and then maybe we can look at
something we know works and see if AWSGI/WSGI differences can be
resolved to bring it back into one spec.  And indeed it's quite
possible at the library level that AWSGI could be supported by other
libraries; I'm guessing for instance that WebOb would just require a
few checks around the request body, and probably the response would
work relatively fine (but for many patterns a normal response object
would not be sufficient in an async context -- but that's fine too).

--
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and async Servers

René Dudfield
I'm pretty sure you can use async sockets + wsgi with Eventlet.
http://eventlet.net/

That shows it's possible to support wsgi with async servers.  Eventlet
is quite nice towards wsgi in this way.

One of eventlets backends is twisted.
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: WSGI and async Servers

Graham Dumpleton-2
In reply to this post by Armin Ronacher
2009/9/18 Armin Ronacher <[hidden email]>:

> 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
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com