On Mar 18, 8:29 pm, Baskaran Sankaran <[email protected]> wrote: > Thats great effort Dustin in removing the redundancy.
(sorry, it's a habit) > Coming back, my simple > test is that the key-miss counts should all be *zero*, because, I've earlier > stored objects for all keys in memcache. But, here the key-miss counts are > *not* zero proving that my purpose is not served. Well, yes. I didn't see that code, though. I'm assuming your client will signal errors properly on storage failures and you're absolutely certain everything you attempted to store made it. I've written a test for checking basic -M support, but it's still not a promise. > Before proceeding, let me explain my requirement clearly. I want to maintain > a huge hash table to store some rules (keys) and their counts (values). The > hash table has to be accessed over the network by multiple processes running > parallely, which would update the count (add the incremental count to the > existing value) for the rules, if they are already present in the hash > table. The first time a rule is seen, it would be 'set' to the hash with the > initial count as value. Once, I finish the process, I would want to write > down the final counts for the individual rules in a file. If you use it as a cache, you can have a backing store that's a more reliable persistent mechanism, and your hit can insert a record into a > I thought that memcahed could be used as a shared hash table, whose values > are to be updated simultaneously by multiple processes It is, but as a cache -- there's no guarantee that it'll hold on forever. Especially considering that you're actually mutating the cache after you load it. An incr *might* cause the server to need to move an item to a different slab. You quite likely could be running out of space. Perhaps posting your stats here would help identify those kinds of problems: stats stats slabs stats items > I tried setting an > expiry time of 60*60*24*3 (3 days) while storing the objects, so that they > will not be removed for making way for other objects. But, this doesn't seem > to work. You probably want an expiration of 0 if your intention is for it to hold on as long as it can. > Now, my question is: is memcache not expected to store the objects at least > till the specified expiry time? I tried using a dbm-hash sometime back and > found that it is *very* slow (coz, my hash table size is going to be huge > having above 20 million rules). > > Hoping that there is some solution for my problem :-) Let's take a look at your stats.
