Task #11517 (new)
Opened 11 years ago
Last modified 8 years ago
Move to Django cache — at Initial Version
| Reported by: | cxallan | Owned by: | mhart-x |
|---|---|---|---|
| Priority: | major | Milestone: | Unscheduled |
| Component: | Web | Version: | 4.4.8 |
| Keywords: | n.a. | Cc: | python-team@… |
| Resources: | n.a. | Referenced By: | n.a. |
| References: | n.a. | Remaining Time: | n.a. |
| Sprint: | n.a. |
Description
The current webgateway caching system relies on a custom implementation which has least recently used (LRU; http://en.wikipedia.org/wiki/Cache_algorithms#Least_Recently_Used), timeout and size features. Unfortunately the way these features are implemented, in particular the LRU semantics can cause real problems with larger caches and under load. At a minimum a pluggable backend is required.
As we have upgraded to Django 1.3.1 the Django cache (https://docs.djangoproject.com/en/1.3/topics/cache/) has had significant increases in maturity. LRU backends with many features are also available such as memcached out of the box and django-redis-cache (https://github.com/sebleier/django-redis-cache).
In order to keep the individual cache settings control of timeouts and LRU pool sizes for thumbnails, JSON and images the following cache names (keys of the Django CACHES setting dictionary) should be used:
- omero.web.json
- omero.web.image
- omero.web.thumbnail
The *entire* API of the WebGatewayCache should be completely untouched after this refactoring and integration tests should be added to cover all public methods. The omero.web.webgateway_cache setting will also need to be deprecated (it's already largely completely hidden) and the omero.web.caches setting documented further.
