Error handling in Cache::Memcached

dormando dormando at
Wed Jul 12 19:48:43 UTC 2006

> The problem with this is that since I still don't know why my get()
> failed, I would need to call this method unconditionally before every
> operation.  That's very expensive.  Optionally die()'ing seems much more
> perlish.
> George

The application doesn't need to know why the get() failed. Check the 
mailing list archives. This has come up a number of times for two 
different reasons:

1) Clients used to, some still, detect when a server goes down, then 
redistributes keys.

2) Figured out that 1) was a bad idea, because the keys get 
redistributed again when the server comes back up, or constantly if it 
flaps. Tons of cache misses! Better to treat everything as a cache miss 
and have a monitoring service actually let you know if memcached is lost 
and gone forever, rather than cause tons of cache misses to redistribute.

So the application *should* only ever see "cache miss", and something 
with more smarts can let it know to update the server list or actually 
fix the bumpkus interface. Alternatively applications can do a 
conditional test; Hey, I'm getting a *ton* of cache misses over period 
of time, lets check to see if the server's up. Nope? Okay, I'll stop 
trying to cache for a while. Can't really think of a place where that'd 
be useful, other than a slight performance advantage of not even trying 
a server if a key resolves out to it.

Also, hey George :P I was at CCI after you left.


More information about the memcached mailing list