

Gevent: the Good, the Bad, the Ugly - btmorex
http://code.mixpanel.com/gevent-the-good-the-bad-the-ugly/

======
amix
Using a non-blocking server with Python does not really make sense since most
libraries in Python are blocking by nature and gevent only solves the most
simple conversions by monkey patching (and like the author notes this is very
error prone).

If you want to use non-blocking in Python then using something like Twisted is
an option since Twisted implements most things in an non-blocking way, but
Twisted hasn't really gained that much traction in the many years of its
existence.

So yes if you do a hello world benchmark then you get a 4x speed improvement,
but if you do any library calls (such as doing a MySQL query) you will get
decreased perfomance since the MySQL Python library is blocking (and most
other libraries are blocking as well)...

~~~
levigross
The advantage here is the usage of Libevent which makes it only listen when a
eventlet sends back a message. It's essentially using the same tech (event
wise) as NGINX.

Because it's using event's it has not blocking IO. But is limited when the
tasks are CPU bound

------
kwellman
The current project I'm working on involves managing and launching a lot of
http requests to different web service api's, and gevent really is the best
thing since sliced bread.

Things like rate limiting (gevent can monkey patch time.sleep), error
handling, and scaling to a large number of concurrent connections (see
gevent.pool.Pool) have been added to my app with surprisingly little increase
in code complexity. The fact that you write your code as if it was synchronous
makes it so much easier to maintain. I don't have to find my way through
callback spaghetti. I also find asynchronous much easier to grok than
threading (and it's also more lightweight)

------
j_baker
This is very interesting, but I don't think comparing it to paste is valid.
Paste is more meant as a development server, is it not?

~~~
ericflo
No, not at all. Well, people do use it for development, but it's pretty much
the recommended deployment option for several Python web frameworks, including
Pylons.

~~~
weixiyen
Not true. Production deployments in Pylons are primarily done with mod_wsgi
behind apache or in some cases uwsgi behind nginx.

Paste is generally not recommended outside of development purposes.

~~~
ericflo
[http://pylonshq.com/docs/en/1.0/deployment/#deploying-the-
ap...](http://pylonshq.com/docs/en/1.0/deployment/#deploying-the-application)

"There are lots of ways of deploying an application, one of which is to use
the paster serve command which takes the configuration file that has already
been used to setup the application and serves it on a local HTTP server _for
production use_."

~~~
weixiyen
I've spent a good year developing with Pylons and this question of recommended
production setup comes up about once every couple months in the official
mailing list. Paste is considered by far the worst option in terms of
performance, which is why most devs go with Apache/mod_wsgi. Nobody recommends
Paste. Some (in my case) deployed with nginx/uwsgi.

~~~
ericflo
The official docs recommend Paste. We've had apps in production running on
Paste since 2007. At the time, neither mod_wsgi or uwsgi were around.
Certainly it may not be the _best_ way to run in production, but it's not for
development only.

------
markitechtMA
I wonder how it might compare to Tornado (<http://www.tornadoweb.org/>)

~~~
Vishnevskiy
I love Tornado personally, but I wanted to write synchronous code.

Eventlet (the project that Gevent forked from) allows you to write hubs while
gevent only supports the libevent hub. So I made
<http://github.com/vishnevskiy/greentornado> to allow Eventlet to run on
Tornado's IOLoop. Been working for a while in production with no issues.

Would have made it for gevent though if I could since after reading the code
of gevent and Eventlet I found that gevent's code base was much cleaner.

~~~
BarkMore
The creators of Tornado recommend writing synchronous code for everything
except "long" operations for which you have no control. Examples of these
include long polling and requests to third party services. Requests to your
local database are not long operations. If these requests are long operations,
then you have a latency problem with your application.

The Tornado people recommend running more instances of the application than
CPUs to handle the short blocking requests to local databases and what not.

Although it depends on what your app does, my guess is that typical
applications written with this philosophy are mostly synchronous code.

~~~
Vishnevskiy
With eventlet and gevent you can write asynchronous that looks synchronous.
Which is the point of greentornado.

That being said we still use synchronous calls to our databases.

------
andrewcooke
how is this better than (the mature, well engineered) twisted?

