Hi, I know that this topic is rather burdened, as it was said often enough that memcached never was created to be used like a reliable datastore. Still, there are users interested in some kind of reliability, users that want to store items in memcached and be "sure" that these items can be pulled from memcached as long as they are not expired.
I read the following on memcached's memory management: "Memcached has two separate memory management strategies: - On read, if a key is past its expiry time, return NOT FOUND. - On write, choose an appropriate slab class for the value; if it's full, replace the oldest-used (read or written) key with the new one. Note that the second strategy, LRU eviction, does not check the expiry time at all." (from "peeping into memcached", [1]) I also found "Slabs, Pages, Chunks and Memcached" ([2]) a really good explanation of memcached's memory model. Having this as background, I wonder how it would be possible to get more predictability regarding the availability of cached items. Asume that I want to store sessions in memcached. How could I run memcached so that I can be sure that my sessions are available in memcached when I try to "get" them? Additionally asume, that I expect to have 1000 sessions at a time in max in one memcached node (and that I can control/limit this in my application). Another asumption is, that sessions are between 50kb and 200 kb. The question now is how do I have to run memcached to "store" these sessions in memcached? Would it be an option to run memcached with a minimum slab size of 200kb. Then I would know that for each session a 200kb chunk is used. When I have 1000 session between 50kb and 200kb this should take 200mb in total. When I run memcached with more than 200mb memory, could I be sure, that the sessions are alive as long as they are not expired? What do you think about this? Cheers, Martin [1] http://blog.evanweaver.com/articles/2009/04/20/peeping-into-memcached/ [2] http://www.mikeperham.com/2009/06/22/slabs-pages-chunks-and-memcached/
