memcached limitations

Question

Has anyone experienced memcached limitations in terms of:

• # of objects in cache store - is there a point where it loses performance?
• Amount of allocated memory - what are the basic numbers to work with?

Answer 1

I can't vouch for the accuracy of this claim, but at a linux/developer meetup a few months ago an engineer talked about how his company scaled memcache back to using 2GB chunks, 3-4 per memcache box. They found that throughput was fine, but with very large memcache daemons that they were getting 4% more misses. He said they couldn't figure out why there was a difference but decided to just go with what works.

Answer 2

I can give you some metrics for our environment. We run memcached for Win32 on 12 boxes (as cache for a very database heavy ASP.NET web site). These boxes each have their own other responsibilities; we just spread the memcached nodes across all machines with memory to spare. Each node had max 512MB allocated by memcached.

Our nodes have on average 500 - 1000 connections open. A typical node has 60.000 items in cache and handles 1000 requests per second (!). All of this runs fairly stable and requires little maintenance.

We have run into 2 kinds of limitations: 1. CPU use on the client machines. We use .NET serialization to store and retrieve objects in memcached. Works seamless, but CPU use can get very high with our loads. We found that some object can better be first converted to strings (or HTML fragments) and then cached. 2. We have had some problems with memcached boxes running out of TCP/IP connections. Spreading across more boxes helped.

We run memcached 1.2.6 and use the .NET client from http://www.codeplex.com/EnyimMemcached/