Libev and libevent | Hacker News Reader

Libev and libevent

blog.gevent.org

50 pointstimf8 comments

"libev is really easy to embed and that’s what we’re going to do for the next version: put all the dependencies in the release tarball. Hopefully this will reduce the number of build problems people get. This will also remove the number of possible variations of gevent because of different library versions used. There still will be an option to dynamically link against the dependencies, it just won’t be the default."

Will this really reduce the number of library version used? I would expect every linux distribution to dynamically link gevent to their existing package of libev.

That seems similar to what Google does with Chrome, which caused problems with packaging, upgrades, and security patching. http://spot.livejournal.com/312320.html

Interesting, I was just trying to figure out how to install this last night on a Ubuntu Lucid VM. Eventually though I just gave in and installed/used pip. Was ultimately successful, although it seems to be using an old libevent 1.4 even though there is a 2.0 out that it is supposed to be faster.

I originally was attracted to gevent after reading about its excellent performance and resource usage. I'd like to use it in concert with nginx to host a django app. I wonder if this is the best choice though? I got it to work, but it seemed a little unnecessarily complex... having to install large dependencies/compile things on the server. Maybe I should just use the wsgi module built into nginx?

These packages are so new I'm not confident on the best course of action.

For django app hosting, I believe the usual good advice is to use something like uWSGI or Gunicorn to manage a load-balanced worker pool, and use nginx in front as a reverse proxy. There are a lot of subtle things that such a configuration does correctly out of the box. It looks like Gunicorn is really easy to set up, uWSGI has more features, and both are good, solid choices that lots of people are using in production:

http://gunicorn.org/

http://projects.unbit.it/uwsgi/

If some parts of your application need to handle loads of concurrent connections (e.g. long polling, streaming, etc.) then you can use something like Tornado or eventlet or gevent to make that part of your app, and stick it behind nginx as well. You can also use the asynchronous worker types supported by Gunicorn and uWSGI. Which one is more straightforward is up to you.

As usual, you'll want to use something like Supervisord, Upstart, or Monit to monitor your daemons and restart them if they malfunction.

Thanks for the info. uwsgi was my second choice, gunicorn didn't seem to have as good performance, but if it is a lot easier I'll give it a try. To be honest, performance isn't a huge concern for my app, but I'm trying to fit it into a ec2 micro and therefore want to squeeze the most from it.

So what's the plan for the missing HTTP feature after the move to libev?

There are 2 possible ways for the next release a) conservative - use libevent's http on top of libev-libevent emulation b) reimplement them; maybe start with an http server that already uses libev, like bjoern

Conservative option might be chosen as a temporary solution if release 0.14 is delayed for too long otherwise.

in my experience a lean mean libevent api is the winner. once i need dns or http for size or speed there are more choices than to bog down the event handler. Yes, I understand the benefit of having dns/http/and who knows what in the event handler. once a program needs event handling for multi platform simplicity still the best way to go. i stopped using libevent since the dns/http stuff was added. and in some cases i had to write event handlers from scratch for different oses to have uniformly good acceptable performance.

Reply on news.ycombinator.com