libevent and epoll
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.
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.