Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.



No description

Thomas Tse

on 14 November 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Memcached

Memcached How it works (Server and Client) How we use it Possible improvements (or not) How it works (Server) Allocated memory is split into 1MB PAGES and assigned to SLABS Each SLAB is responsible for storing CHUNKS of a certain size A CHUNK is the value to be stored + it's key How it works (Server) So... ... Slab 1 (0-80 bytes) Slab 2 (81-104 bytes) Slab 3 (105-136 bytes) 56 bytes 32 bytes 99 bytes 121 bytes In this example, 15 bytes is wasted by storing the 121 byte chunk How it works (Server) Other interesting bits... Pages are assigned to slabs on demand Once assigned to a slab, a page cannot be moved to another. (In a newer version of Memcached there's a manual command that allows you to do this) How it works (Client) Given that we use more than one Memcached instance, where does my value get stored?? Where this gets stored is dependent on the hashcode() of your key ...
MemcachedNodes[] nodes = ...
int index = key.hashcode() % nodes.length
return nodes[index]

(from net.spy.memcached.ArrayModNodeLocator)
There are other hash algorithms and NodeLocator classes, but this appears to be the default How it works (Client) What this means for us? It's important to have the same cache servers configured for all nodes for a given app.
If different apps wants to use the same cache key, then they must also use the same list of cache servers. Also note that spymemache's add/get/set methods are asynchronous. But npg-commons hides this for us. How we use it We have 2 instaces of Memcached running on 2 different servers (npgcache1 and npgcache2) Some stats (after being up for 45 days): npgcache1 Gets received npgcache2 Get hits Hit rate Sets received Evictions
listen_disabled_num 642699085 636601272 99.05% 8135875 0 0 574944800 568810705 97.4% 7891189 0
0 npgcache1 gets used slightly more than npgcache2 (52.78% of gets go to it) How we use it How big are the things we store in Memcached?? How we use it ... but of that, what do we actually use?? Used bytes Max bytes Memory usage 965062213 12884901888 7.5% 900020612 12884901888 7% How we use it Conclusion: We have a high hit rate, plenty of memory, no evictions, an even split between the instances and is always listening for new connections. There doesn't appear to be any obvious config problems... Possible Improvements There doesn't appear to be any improvements to be gained by changing configuration. But how about in changing Memcached and the client itself? We currently use Memcached 1.4.5 and Spymemcached 2.6. Would things improve if we use Memcached 1.4.15 and Spymencached 2.8.4?
Full transcript