A smarter local memory cache backend for Django
Project description
A global object cache backend for Django.
About
lrucache_backend is an in-memory cache that has differing goals to the LocMemCache backend that Django provides.
Originally its purpose was to improve the cache eviction strategy, using an LRU algorithm over a random cull. However, Django 2.1 changed the LocMemCache to also use an LRU strategy.
Now, lrucache_backend has two major differences from Django.
Eliminates key char validation, improving performance at the cost of not being portable with memcache backends.
Eliminates serialization (pickling), allowing instances to be shared across requests. Any mutations performed on cache objects are maintained.
lrucache_backend functions as a global object cache, and uses a familiar Django interface to avoid poorly reimplementing local object caches in service layers:
def get_data_before(self):
if not hasattr(self, '__data'):
self.__data = self.expensive_query()
return self.__data
def get_data_after(self):
lcache = caches['local']
data = lcache.get('our_data')
if not data:
data = self.expensive_query()
lcache.set('our_data', data, timeout=600)
return data
The benefits (despite the longer method) include timeouts, sharing data between requests, and avoiding network requests. This is especially useful when there are hundreds or thousands of property accesses that would hit the cache where network overhead would be prohibitive. The Fat model pattern can greatly benefit from tiered caching.
Good for?
An in memory cache is good for small data that changes rarely. It’s effectively a global dictionary shared between requests in the same process. Small lookup tables and database backed settings are good candidates.
A small number of keys should be used to avoid engaging the culling strategy of the cache. Performance goes down fast as soon as the maximum number of keys are reached, and keys start to evict.
This should not be used as your primary cache, but it makes for an excellent secondary cache when you want to avoid the overhead of a network call.
Use for:
Small lookup tables
Settings
Backing store for your service objects
Remembering values for the duration of a request or celery task
Small global template fragments like sidebars or footers
Secondary cache
Bad for?
An in memory cache is terrible for data that changes often. Because the cache is process local, it’s extremely difficult to coordinate cache invalidation from external processes. For that reason, this library does nothing to support cache invalidation.
The cache shares memory with the application, so it’s extremely important to avoid storing a lot of keys, or any large values.
Do not use for:
Instance attributes/properties
Full templates
Tables with a large number of rows
Large values
Large lists
Primary cache
Differences from LocMemCache
Avoids pickling
Avoids key name validation
Installation
pip install django-lrucache-backend
Requirements
There are no longer any external dependencies. lru-dict used to be a dependency, but as since been replaced with the built in OrderedDict as a consequence of now deriving from the built in LocMemCache.
Usage
Configure your CACHES Django setting appropriately:
CACHES = {
'local': {
'BACKEND': 'lrucache_backend.LRUObjectCache',
'TIMEOUT': 600,
'OPTIONS': {
'MAX_ENTRIES': 100,
'CULL_FREQUENCY: 100,
},
'NAME': 'optional-name'
}
}
- Note:
Set CULL_FREQUENCY == MAX_ENTRIES to only delete a single key per cull to only eliminate a single entry per cull. This maintains the LRU property most effectively, but can have performance implications.
And then use the cache as you would any other:
>>> from django.core.cache import caches
>>> local = caches['local']
>>> local.set('key', 123)
>>> local.get('key')
... 123
If you’re going to use this cache backend, then it’s highly recommended to use it as a non-default cache. That is, do not configure this cache under the default name.
Local memory caches compete for memory with your application so it’s in your best interests to use it as sparingly and deliberately as possible.
Compatibility
Django 2.2+ Python 3.6+
Licence
MIT
Project details
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
File details
Details for the file django-lrucache-backend-4.0.0.tar.gz
.
File metadata
- Download URL: django-lrucache-backend-4.0.0.tar.gz
- Upload date:
- Size: 5.6 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: poetry/1.0.5 CPython/3.6.10 Darwin/19.3.0
File hashes
Algorithm | Hash digest | |
---|---|---|
SHA256 | af0906261e4d8a66f7031de0e5cd70a5375791f6321429fe6c90c240f02c9ca4 |
|
MD5 | 046bf1abca91fdf9d2b27c39f7f35786 |
|
BLAKE2b-256 | 597d76824895e169e88195cbae025a1d0caa5aac313ad4294da93b235ab1172e |
File details
Details for the file django_lrucache_backend-4.0.0-py3-none-any.whl
.
File metadata
- Download URL: django_lrucache_backend-4.0.0-py3-none-any.whl
- Upload date:
- Size: 5.4 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via: poetry/1.0.5 CPython/3.6.10 Darwin/19.3.0
File hashes
Algorithm | Hash digest | |
---|---|---|
SHA256 | 9d04d5d9a75408dd84c4d1855d9ae6b8d775f1c3dcbc434b54cac7233c0e7ca7 |
|
MD5 | 698984d9a0316367385e0ddc3522d92b |
|
BLAKE2b-256 | 65231eee3b6252c89f02b4861ff83f0e2de4361793f6a1002f89aa2421e509c8 |