

Libev and libevent - timf
http://blog.gevent.org/2011/04/28/libev-and-libevent/

======
sciurus
"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.

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

------
mixmastamyk
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.

~~~
pjscott
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.

~~~
mixmastamyk
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.

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

~~~
denik
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.

------
peterbotond
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.

