libevent and epoll

[Perrin Harkins]

Brad,

>   * Your connect to MySQL is over "localhost", which the mysql client
>     remaps to using a Unix socket.  Change it to using TCP and watch DBD
>     perf drop quite a bit.

I will try that.  I thought it only used unix sockets if I told it to at
compile time.

>   * You're ignoring concurrency issues.  Increase your clients to more
>     than 1 and watch DBD performance drop because MySQL starts locking.
>     Sure, you could use InnoDB (concurrent, but slow) or HEAP tables,
>     but HEAP tables are very limiting.

I actually do have a much more complete test that does concurrency,
varies the percentage of writes to reads, tests the storage of complex
data, and increases the size of the data set and individual values. 
It's all done with a mod_perl handler and a HTTP load generator.  What I
sent you is my basic test that I use when adding new drivers.  The more
complete test is being revised right now, and I intend to put the whole
thing up on CPAN for people to play with after that.  (By the way, how
about putting MemCachedClient on CPAN?  Maybe as IPC::Memcached or
something?)

Having said that, I found that concurrency didn't make very much
difference.  Even in the case of things like MLDBM::Sync, which lock the
whole database during writes, relative performance of these tools was
about the same with many concurrent clients as it was in the single
client test.  I haven't tried it yet with memcached because I wanted to
see if I was doing something wrong first.

In my experiments with MySQL, heap tables have about 50% better
performance, but they can't store anything larger than a varchar 256 so
they're basically useless.

>   * Your dataset is so small, MySQL and the kernel buffer cache never
>     actually writes.

Yes, this is true.  I use a larger data set in the other test.  Even so,
my goal is not to use more data than can fit in memory.  You wouldn't
recommend that people run memcached in a way that would cause it to
swap, would you?

> I'll work on tuning the Perl to be faster first.

I plan to run it through the profiler later on and see if there's
anything obvious to tune.

Thanks for your feedback.

- Perrin