libevent and epoll
29 Sep 2003 16:05:58 -0400
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.