Profiling Django-Cachalot about django-cachalot HOT 2 CLOSED

After a little more digging, I've found that invalidating tables doesn't actually delete any keys from cache. It waits for LRU to evict old keys, which is most efficient (no use deleting keys in practice). However, it does make it really hard to determine how much space Django-Cachalot requires in production to operate at maximum efficiency. What about adding a table prefix to each cache_key, and then build a management function that deletes all expired cachalot keys? This would be very inefficient, but could be used sparingly to understand how much space cachalot is actually using.

from django-cachalot.

First of all, you should set the memcached memory limit. Once it’s set, there’s no surprise: it will not take more than what you allow. And therefore no need for profiling.

Now, it would indeed be great to have better tools for profiling caches. Unfortunately, caches absolutely don’t work like a database, and that’s the cost for being as fast as possible. The only reliable thing with a cache is: asking for what’s stored at a certain key, and set the value for a certain key. Forget what you think you know about timeouts etc: none of it is reliable. If you create a key with an infinite timeout, it can very well be removed before a key with a 1 second timeout (if you want to know more about it, read this article in the Redis docs).

I’m sorry, but there’s no viable solution to make a command that deletes expired cachalot keys. I know it could be possible using Redis (or using other caches with non-standard hacks), but that would take hours on a big cache…

However, because tons of people requested it, I will add a way to specify cachalot’s timeout in the upcoming major release… For me, there is no good reason to use it, configuring properly the cache backend is the solution, not using a timeout that doesn’t work as 99.5% people think it does. But if users feel at home by having it…

from django-cachalot.