The SIGPIPE issue has been distracting.  I originally set out to look at
scenarios when a running application experiences a failure in a
memcached server, and to test with consistent hashing.


Say I have six memcached servers.  If I lose a server I lose what was
stored in that server.

So, I'm looking at the situation were a server goes down and then a
new server is brought up in its place (but obviously w/o any data).
So, I'm looking at the hit and miss ratio while one server is down and
when it is then later replaced.

This is just a first pass at looking at this, but consistent hashing
seems to do slightly better, but only if "memc" is persisted the
entire time a server is lost and brought back up (empty).  If memc is
not persisted then it does much worse.  And with forking app servers
can't be sure when a server is restarted.

So, I create six memcached servers, write 40K items, and then kill a
server, check my hits and misses, then start up a new server on the
same port.

I'm ignoring SIGPIPE.  And I'm only looking at reads from a populated
cache.  It is too early (in these tests and in the morning) to draw
any conclusions.  Plus, I'm well aware of my limited understanding of
memcached and the hashing algorithms.  I suspect this makes perfect
sense to those that know about this stuff. ;)


Caching "YES" means caching for the entire pass (including
dropping and restarting a server), where "NO" means only that a
new memc was created after each pass at reading all entries in the
cache (not a new memc between each memcached_get).


Caching Connection: NO
Ketama: NO
Hit: 33347.  Miss: 6653.  Total: 40000 (drop server)
Hit: 33347.  Miss: 6653.  Total: 40000 (replace server))


Caching Connection: YES
Ketama: NO
Hit: 33340.  Miss: 6660.  Total: 40000 (drop server)
Hit: 33339.  Miss: 6661.  Total: 40000 (replace)


Caching Connection: NO
Ketama: YES
Hit: 34012.  Miss: 5988.  Total: 40000 (drop server)
Hit: 29204.  Miss: 10796.  Total: 40000 (replace)


Caching Connection: YES
Ketama: YES
Hit: 34088.  Miss: 5912.  Total: 40000 (drop server)
Hit: 34087.  Miss: 5913.  Total: 40000 (replace)


Of course, where the consistent hashing helps is when the number of
servers changes.

Without caching AND changing the server list after dropping a server:

Ketama: NO
Hit: 6746.  Miss: 33254.  Total: 40000 (connecting with 5 servers)
Hit: 33315.  Miss: 6685.  Total: 40000 (replace and connect with 6)

Ketama: YES
Hit: 34248.  Miss: 5752.  Total: 40000 (connecting with 5 servers)
Hit: 29382.  Miss: 10618.  Total: 40000 (replace)

In this case is looks like Ketama helps if you simply drop the server,
but if that server is the server is replaced it's worse.







-- 
Bill Moseley
[EMAIL PROTECTED]

Reply via email to