Performance: Caching views
Certain views e.g. /users/
or /circles/
, will have the same output regardless of the user. Views like this can have their output cached to improve performance
Cache install
The first part of this task involves setting up the cache
Django provides native support for 3 production-appropriate cache types:
- Memcached: entirely in program memory. The fastest, most efficient type of cache supported natively by Django. Memcached runs as a daemon and is allotted a specified amount of RAM. Being stored in RAM, the caching here is particularly temporary
- Database caching. This requires custom routing code if you use multiple databases
- Filesystem caching
Different clients may have different preferences between these. My suggestion is that we support one, for now
Work will be required in sib-manager to automatically produce the settings for the cache, and the user can override this to change settings like the timeout and max entries. If using memcached it will also need to auto start the daemon and I don't know how easy this would be, and probably it would be best to be activated only by a user argument
For these reasons possibly the file system cache is the easiest, or the database cache (if it's safe to assume there won't be any clients who use multiple databases for the time-being, or if they can provide their routing logic)
@plup @jbpasquier I will need some help with the estimation for this part
Cache application
The cache can be applied site-wide or on specific views, but I think in our case it's not safe to assume that the cache should be applied to every view
Client's can decorate custom views easily with their cache
It can also be done in the urlconf, which would be advisable for caching the dynamically-generated view-sets
- the user should be able to enable/disable the cache at the view level and the model (Meta) level
- @balessan it seems parent views can generally be assumed as safe to cache, can detail views? Can nested views?
- the cache lifetime can be configurable on the model/view
- do we assume that certain views have the cache applied by default, or does it need the client to activate it in the Meta or viewset? Perhaps we can make this configurable for the client by a custom setting
- if it's a simple boolean
cache_parent_view
, it's easy UX in the Meta. But if it's a list, likecache_nested_fields_views = ['circles', 'members']
, it's a lot more complex, and we're presented with the same reverse problem we had when refactoring nested fields( #253 (closed))
For this part I estimate 4 hours