System architecture best practices - memcached + webfarms

Jan Miczaika jan at hitflip.de
Mon Jul 9 12:06:03 UTC 2007


We've had situations where the death of a memcached server caused the 
database to overload, since this server contained a significant part of 
the cache. With dozens or hundreds of web slaves requesting the same 
data, the cache doesn't fill properly, as no process ever reaches the end.

What we did:
- write scripts to "warmup" the cache before the site goes live again, 
to prevent the first visitors from killing everything again. These were 
dumb in the beginning (simply crawl the page in the background while it 
is offline) but got smarter (warmup the cache with the data that has the 
most impact (expensive to get and often requested)).

- dividing up the data and the number of servers in a way that the 
database can handle the death of one memcache (and of course the 
regeneration of cache keys on another system) without db problems. doing 
tests we found a sweet spot at about 6-8 machines running memcache 
instances (with larger cache sizes than 2 GB). Having one of these fail 
will not compromise the database. Below 4 machines running memcache the 
failure of one gets critical.


More information about the memcached mailing list