[Web-SIG] PEP 444 and asynchronous support, continued
After a weekend of experimentation with several asynchronous frameworks including gevent, tornado and twisted (and writing one myself too), and these are my findings so far: - asynchronous socket implementations vary wildly across different frameworks - gevent is the fastest, tornado comes second while twisted is pretty slow - twisted provides the most comprehensive support for implementing protocols, while the other two mostly just provide low level support for asynchronous sockets - futures seem to have a significant overhead (from the thread synchronization) - gevent provides the easiest programming interface with greenlets, since it pretty much lets you write asynchronous code as you would write it synchronously - gevent could make use of the regular, synchronous PEP 444 API by monkey patching the socket library (through its import monkey; monkey.patch_socket() call) The significance of this for the Python web standards effort is that providing an asynchronous API that works for the existing asynchronous frameworks does not seem feasible. I'd love to see a solution for this in the standard library, but gevent's monkey patching approach, while convenient for the developer, cannot obviously work there. Before an asynchronous WSGI API can be provided, this lower level problem needs to be solved first. The crucial question is: is it possible to provide gevent's level of convenience through the standard library, and if not, what is the next best solution? I'd like to hear everyone's thoughts on this (especially Guido's). ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] PEP 444 and asynchronous support, continued
On Jan 16, 2011, at 10:49 PM, Alex Grönholm wrote: After a weekend of experimentation with several asynchronous frameworks including gevent, tornado and twisted (and writing one myself too), and these are my findings so far: - asynchronous socket implementations vary wildly across different frameworks That's certainly true. - gevent is the fastest, tornado comes second while twisted is pretty slow Fastest at... what? If you have a WSGI benchmark for Twisted, could you contribute it in a form that we could use at http://speed.twistedmatrix.com/ so that we can improve the situation? Thanks. - futures seem to have a significant overhead (from the thread synchronization) If there were some way to have tighter control over where the callbacks in add_done_callback were executed, thread synchronization might not be necessary. The module as currently specified does need to have a bit of overhead to deal with that, but the general concept doesn't. The significance of this for the Python web standards effort is that providing an asynchronous API that works for the existing asynchronous frameworks does not seem feasible. I don't see how that follows from anything you've said above. I'd love to see a solution for this in the standard library, but gevent's monkey patching approach, while convenient for the developer, cannot obviously work there. gevent and eventlet don't need any special support from WSGI though. It's basically its own special kind of multithreading, with explicit context-switches, but from the application developer's perspective it's almost exactly the same as working with threads. The API can be the existing WSGI API. Twisted and Tornado and Marrow (and Diesel, if that were a thing that still existed) do need explicit APIs though, and it seems to me that there might be some value in that. For that matter, Eventlet can use Twisted as a networking engine, so actually you can already use Twisted asynchronously with WSGI that way. The whole point of having an asynchronous WSGI standard is to allow applications to be written such that they can have explicitly-controlled event-driven concurrency, not abstracted-over context switches in a convenience wrapper. Before an asynchronous WSGI API can be provided, this lower level problem needs to be solved first. I'm not even clear on what lower level problem you're talking about. If you're talking about interoperability between event-driven frameworks, I see it the other way around: asynchronous WSGI is a good place to start working on interoperability, not a problem to solve later when the rest of the harder low-level things have somehow been unified. (I'm pretty sure that's never going to happen.) The crucial question is: is it possible to provide gevent's level of convenience through the standard library, and if not, what is the next best solution? I'd like to hear everyone's thoughts on this (especially Guido's). gevent and eventlet already have things that will monkey patch the socket module that the standard library uses (for example: http://eventlet.net/doc/patching.html), so ... yes? And if this level of convenience is what you're aiming for (blocking calls with an efficient, non-threaded scheduler), again, you don't need async WSGI for that. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
Re: [Web-SIG] PEP 444 and asynchronous support, continued
17.01.2011 06:47, Glyph Lefkowitz kirjoitti: On Jan 16, 2011, at 10:49 PM, Alex Grönholm wrote: After a weekend of experimentation with several asynchronous frameworks including gevent, tornado and twisted (and writing one myself too), and these are my findings so far: - asynchronous socket implementations vary wildly across different frameworks That's certainly true. - gevent is the fastest, tornado comes second while twisted is pretty slow Fastest at... what? If you have a WSGI benchmark for Twisted, could you contribute it in a form that we could use athttp://speed.twistedmatrix.com/ so that we can improve the situation? Thanks. I'm already regretting saying anything about performance. Our tests were run with the Apache Benchmark (ab) against a Hello World type WSGI app. Certainly nothing special. - futures seem to have a significant overhead (from the thread synchronization) If there were some way to have tighter control over where the callbacks in add_done_callback were executed, thread synchronization might not be necessary. The module as currently specified does need to have a bit of overhead to deal with that, but the general concept doesn't. Unfortunately you are wrong. Thread synchronization is not necessary for callbacks, but it is necessary for supporting the result() method, since other threads may be blocking on that call. The significance of this for the Python web standards effort is that providing an asynchronous API that works for the existing asynchronous frameworks does not seem feasible. I don't see how that follows from anything you've said above. Asynchronous apps (save for gevent and the likes) can't use the standard wsgi.input since reading would block the event loop. Therefore an alternative input has to be provided, right? How would that work then? If something, say, wsgi.async_input was to be provided, what would it return from .read()? Futures? Deferreds? I'd love to see a solution for this in the standard library, but gevent's monkey patching approach, while convenient for the developer, cannot obviously work there. gevent and eventlet don't need any special support from WSGI though. It's basically its own special kind of multithreading, with explicit context-switches, but from the application developer's perspective it's almost exactly the same as working with threads. The API can be the existing WSGI API. Twisted and Tornado and Marrow (and Diesel, if that were a thing that still existed) do need explicit APIs though, and it seems to me that there might be some value in that. Which leads to the problem I described above. For that matter, Eventlet can use Twisted as a networking engine, so actually you can already use Twisted asynchronously with WSGI that way. The whole point of having an asynchronous WSGI standard is to allow applications to be written such that they can have explicitly-controlled event-driven concurrency, not abstracted-over context switches in a convenience wrapper. It is my understanding that eventlet only runs on CPython. Am I mistaken? Before an asynchronous WSGI API can be provided, this lower level problem needs to be solved first. I'm not even clear on what lower level problem you're talking about. If you're talking about interoperability between event-driven frameworks, I see it the other way around: asynchronous WSGI is a good place to start working on interoperability, not a problem to solve later when the rest of the harder low-level things have somehow been unified. (I'm pretty sure that's never going to happen.) The crucial question is: is it possible to provide gevent's level of convenience through the standard library, and if not, what is the next best solution? I'd like to hear everyone's thoughts on this (especially Guido's). gevent and eventlet already have things that will monkey patch the socket module that the standard library uses (for example:http://eventlet.net/doc/patching.html), so ... yes? And if this level of convenience is what you're aiming for (blocking calls with an efficient, non-threaded scheduler), again, you don't need async WSGI for that. That's what I've been saying. But that only holds true for gevent/eventlet. Twisted, for one, needs explicit support unless, as you said, is used through eventlet. ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/alex.gronholm%40nextday.fi ___ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
