Problem with Django Cache Page/URL

Question

I found a problem using the @cache_page(60 * 15) Django in my case. The first user to give the first F5, the page will be locked with the DELE user logged in. So even if I sign in with another user, the page will get the other user account stuck in the cache. That’s bad.

I tried using that cache in the template, but the performance problem comes from the VIEW so it doesn’t scroll.

The point is: my filter is very heavy and I have already made several adjustments to decrease. It reaches an average of 180ms to 200ms in DEV and in production goes there to 300-400ms. That’s a grotesque delay in my case.

When I used Django’s cache through the URL or this cache_page went to 8ms, it was beautiful. But nothing is perfect. I wonder if anyone has any alternative or know how to work with such cases.

This is my setup on settings.py

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
        'LOCATION': 'unique-snowflake',
    }
}

Answer 1

What you call a "problem" when using the @cache_page(60 * 15) Actually it’s not a problem it’s just him doing his job properly. I have no way to give a definitive solution to your case, but I can put some scenarios and you try to find the one that best "matches" your problem. I’ll split it into two main cases. Taking into account that you have a very heavy filter (for a query) you need to answer yourself the following question:

All users have the same answer for this query?

• If your answer is yes, you may not need to cache the page but the query itself, there are some ways to do this in Django optimally and if the answer is yes you will be in a "comfortable scenario".

• If the answer is no, then the "user" is probably part of that query you created. So for each user there may be a different answer and we have a slightly bigger problem. A cache in the query itself may help, but you will use the user id in some form of hash to identify that query (saved) corresponds to a particular user. This problem is a little bigger, because depending on the size of your application this cache (from Django itself) can consume a lot of memory and you will still need to keep an eye on your server structure, because the query may already be cached in one of the two server instances and not in the other (if your server has multiple instances).

This problem of caching in dynamic pages is very big on the internet, so some pages use the cache in the browser itself.