libevent and epoll

[Perrin Harkins]

On Mon, 2003-09-29 at 15:42, Brad Fitzpatrick wrote:
> When you write your article, please either leave memcache out, or address
> its real nature

Take it easy.  I've done several comparisons like this in the past
(inlcuding one on the flame-a-minute world of templating tools), and
have never received any complaints about the fairness of the
comparisons.  The article will include results from benchmarks using
varying concurrency, read/write ratios, and value sizes, as well as
discussions about the nature of the different tools.  I fully intend to
mention the things that make memcached different from the other tools,
since that is the point of the article: helping people choose the right
tool for their situation.  If you're still concerned, I can send you a
copy of the powerpoint slides from the older presentation I did on this.

> I'd hate
> for some pour soul to start using Cache::Cache with its shared memory
> backend because it's n% faster or only n% slower than memcache.

Cache::Cache is one of the worst-performing modules, especially when
using shared memory.  The shared memory modules in general perform very
badly, with the exception of IPC::MM.  This non-intuitive result is one
of the major reasons to publish an article on this subject.  At the
moment, BerkeleyDB (not DB_File), IPC::MM, and MySQL are the top
performers, and your patch will put memcached in that group as well.

- Perrin