Eventlet 0.7
Eventlet 0.7 fixes some very long-standing bugs. First of all, there was a CPU leak in the select hub which would cause an http keep-alive connection to consume 100% CPU while it was open. The problem was that every file descriptor was being passed in to select, even if the callback for the readiness mode was None. This bug has been in since the very beginning of eventlet, and it's great to have it fixed!
Second, another old bug. It's now possible to use Eventlet's SSL client to talk to Eventlet's SSL server. There was a subtle bug in the way SSL sockets would raise an error in some conditions instead of returning '' to indicate the connection was closed.
Finally, some memory leaks in the libevent and libev hubs (fairly new code) were fixed, so if you're using Eventlet with libevent or libev try it out and see how it performs for you.
Also, this release pulls in a bunch of API additions from the Linden SVN repository. Ryan Williams is now maintaining an HG repository which is synched with the SVN repository, so integrating patches between branches will now be much easier.
Update July 30, 2008This release of eventlet also supports stackless-pypy again. I had to check for the absence of the socket.ssl object, and re-enable the poll hub. To try this out, check out and translate pypy-c following the instructions on the pypy site, and then run one of the eventlet examples (for example, "./pypy-c /Users/donovan/src/eventlet/examples/wsgi.py")
Download Eventlet 0.7 from PyPI: http://pypi.python.org/pypi/eventlet/0.7
Spawning 0.7
Spawning has improved a lot since I last wrote about it. It now has a command line script, "spawn", which makes it easy to quickly serve any wsgi application. The concurrency strategy is also now extremely flexible and can be configured for a plethora of use cases.
The default is to use one non-blocking i/o process with a threadpool, which makes it easy to use with any existing wsgi applications out there that assume shared memory and the ability to block.
However, it's possible to independently configure the number of i/o processes, the number of threads, and even configure it to be single-process, single-thread, with fully non-blocking i/o (thanks to eventlet's monkey patching abilities).
Update July 30, 2008This release of spawning also has an experimental Django factory. To run a Django app under Spawning, run "spawn --factory=spawning.django_factory.config_factory mysite.settings".
Take a look at the Spawning PyPI entry for more information: http://pypi.python.org/pypi/Spawning/0.7
3 comments:
I've been trying out Spawning some today - and it totally kicks ass!
It's so fast it's silly! Although it uses a little bit more RAM than apache with mod_wsgi, it seems to be a lot more resource efficient.
Thanks for this app! :-)
Is it possible to run multiple django sites under one instance of spawning? Kind of like apache's virtual hosts mechanism?
@Oscar Carlsson: Thanks for the praise, and thanks for trying out Spawning!
@nuggien: It should be pretty easy to find some WSGI middleware that does Virtual Hosting. Basically, it would look at the Host: header and choose which WSGI application to send the request to. There's nothing in Spawning for doing this out of the box, but it's a good candidate for addition since virtual hosting is such a common use case. I'll think about it and see if there's an easy way to add it that makes sense.
Post a Comment