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 at<http://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
