libevent and epoll

Brad Fitzpatrick
Thu, 11 Sep 2003 14:11:56 -0700 (PDT)

Here's a static binary with epoll and patched libevent:

It'll be way easier for you to use 2.4 than a 2.6 kernel.  Don't use
libevent from DAG.  0.7a is buggy with epoll.  Don't benchmark with
anything but epoll (or kqueue on BSD), because libevent's select/poll seem
to sometimes be buggy on some systems.

We should be way faster than both BDB and IPC::MM (plus we're
distributed... both BDB and IPC:MM are limited to a single host).

Let me know what you find.

- Brad

On Thu, 11 Sep 2003, Perrin Harkins wrote:

> On Thu, 2003-09-11 at 16:25, Brad Fitzpatrick wrote:
> > You don't need 2.6 for epoll; there's a 2.4 backport of it that works
> > beautifully.  It's just a small kernel patch away.
> Now I have to decide if it's simpler to try a 2.6test4 RPM or rebuild
> the 2.4 kernel.  Hmmm...
> > Building libevent with epoll support is trickier than rebuilding the
> > kernel... you have to mess with some headers in /usr/include/, but it's
> > fine.
> I was able to build a source RPM from DAG on my 2.4 system:
> I was also able to build memcached against that, but it complained at
> startup about epoll functions not being implemented.  I think that
> complaint comes from glibc.  I stopped there, so I'm not sure if it was
> falling back to select or just not functional.
> > I've been meaning to put up the latest binary
> Hmmm, I didn't even know there were binaries.  Maybe you could add a
> link on the downloads page?
> FYI, I'm installing this so I can add it to a set of benchmarks I'm
> doing on various Perl modules that provide caching.  So far, the fastest
> are BerkeleyDB and IPC::MM (uses the mm shared memory library).  Both of
> these are about three times as fast as MySQL.
> Thanks,
> Perrin