6

I'm looking for suggestions for an efficient solution for dealing with opening memcached connections given the FAQ quote:

Remember nothing is stopping you from accidentally connecting many times. If you instantiate a memcached client object as part of the object you're trying to store, don't be surprised when 1,000 objects in one request create 1,000 parallel connections. Look carefully for bugs like this before hopping on the list.

See also: Initializing a Memcached Client and Managing Connection Objects.

I considered using a singleton in our caching assembly to provide the memcached client, though I'm sure there must be better methods as the locks would introduce (unneeded?) overhead.

I am clear on the patterns for use of the client, what I'm not clear on is how to use the client efficiently with regards to scalability and performance. How do other people deal with using the memcached clients?

There's a bounty of 50 in it for you.

Justin M. Keyes
  • 6,679
  • 3
  • 33
  • 60
Mr Shoubs
  • 14,629
  • 17
  • 68
  • 107

1 Answers1

3

We had a similar scenario with a redis client, and originally our solution was to have a common single instance that we synchronised access to via lock. This was fine, but to avoid the latency and blocking we eventually wrote a thread-safe pipelined client, which allows concurrent use without any blocking. I don't know as much about the men ached protocol, but I wonder if something similar could apply here. I'm actualy tempted to try investigating to see if I could add this to BookSleeve (our custom OSS redis client) if you can wait a little while.

But we were generally able to keep up just using a synchronised shared instance (pretty much the same thing as a singleton, depending on how purist you are).

Glancing at the FAQ, pipeline is indeed a possibility; and I'm entirely open to the option of writing an async/pipelined memcached client inside booksleeve. Most of the raw IO / multiplexing would be pretty common with redis. The other tricks you can consider is using get_multi etc rather than separate gets where possible - I don't know whether your current client supports this, though (IK haven't looked).

But: I don't know how it contrasts memcached to redis, but in our case, switching to a pipelined/multiplexed API meant we didn't need to use much pooling (many connections) - a single connection (properly pipelined) is capable of supporting lots of concurrent usage from a single node.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
  • I think data is simply transferred in binary format to the servers from the client. The servers seems to open x number of connections from each memcached client instantiation. It makes me wonder if you could use something like a semaphore to allow x number of threads to access it at once? – Mr Shoubs Apr 28 '11 at 20:07
  • We don't use Redis and have a Postgres back-end, I don't really need anything for a persistent store as we have that already. However, your comments on multi get etc are correct, even if they sound complicated (I really don't have the time to write code to pipline a client), though I did ask how other people dealt with this, and no one else provided anything useful, so you get the 50. :) – Mr Shoubs May 10 '11 at 14:28
  • @MrShroubs meh, it (pipelining) might be easier than you think. When I get chance (after my next pb-net grok session) I'll try to update BookSleeve – Marc Gravell May 10 '11 at 14:59