Backend-level expiration / resource deallocation

[sermoz]

Can someone please either confirm or refute my understanding: unless I specify the arguments.memcached_expire_time config option, the keys/values never actually expire in the Memcached itself. It's just that Dogpile considers them expired by checking the expiration times, but actual data don't get deallocated from the underlying Memcached storage (which is RAM). This is probably also true for other backends.

I'm actually concerned about resource deallocation by Memcached. And I guess the reason that the current behavior does not lead to (m)any complaints/problems in practice is that Memcached is typically configured with some memory limit, and when it's reached it's just starting to evict old keys.

So, to summarize it: under typical configuration of Dogpile (no arguments.memcached_expire_time specified), cached data is not deleted from Memcached leading to more resource usage than with that config option set to a reasonable timeout.

(Of course, I'm assuming that we're not calling cache_region.delete() explicitly.)

[jvanasco]

Yes, that is basically what happens with memcahed and most other backends.

If you set memcached_expire_time for a region, Dogpile will explicitly tell memcached to expire/evict the key after that time. If that arg is unset, you are implicitly telling memcached to handle evicting the keys as it sees fit - which will be based off it's own LRU logic.

Dogpile essentially caches data in the form of:

key -> serialized({metadata:{expiry=foo}, value=data})

The metadata contains an expiry, because not all backends support expiry and there are some edge situations where you need the expiry in Python.

If you want to play with performance, you can use custom serializers and classes to change various features.

[sermoz]

@jvanasco Thanks for reply!