User Story #1774
Updated by Sebastian Manger almost 7 years ago
h2. Intro
The full configuration (='empty paper questionnaire') takes up to 10 seconds to initialize. We therefore use 'caching', so it is initialized only once, but 'served' to people accessing qcat from the cache - which is very fast. While caching is optimized to store many 'small' objects, we store few 'big' objects - so we added an additional workaround. This is now causing problems.
h2. Decision:
* Drill down the cache usage. We have to find out what is really stored there and why it does grow that much.
h2. What happens if we don't implement this?
* qcat.wocat.net will take a long time to load (~10 seconds) for more and more users ('performance spikes'). The more configurations / versions / languages there are, the more often these spikes.
* The nicer, but more expensive way would be to change the way configurations are cached - as 'many small items'. See issue #1793 XXX
h2. Technical Detail:
The configuration objects is stored in memcache and the (uwsgi) process. The latter is a workaround, as serializing the object from memcache in python takes approx. 3 seconds. Therefore, the serialized objects from memcached are stored in the uwsgi process as 'last recently used' objects. As the uwsgi processes have an upper limit of consumed RAM and are restarted after the limit is reached, more configs = more trouble. As of now there are about 500 cache misses per day.
But there is still an important open question:
* The size one configuration(technology) in one language is: 20MB
* This multiplied with the number of configurations (5) and the number of languages (6) would give: 5 * 6 * 20 MB = 600 MB
But the cache keeps growing and reaches 2 GB after a few days.