WOCAT » QCAT

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.

Decision:¶

• Drill down the cache usage. We have to find out what is really stored there and why it does grow that much.

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

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.

Failed fix

Split configuration caching into sections. Try this asap, with A/B testing (cde staff).
This is just another 'plaster', but a refactor of the whole configuration object would be too time consuming.