Problem with Django Cache Page / URL

Question

Problem with Django Cache Page / URL

Navigation

#1 by (1 votes)

0

I encountered a problem using @cache_page(60 * 15) of Django in my case. The first user to give the first F5, the page will get stuck with the DELE user logged in. So even if I enter another user, the page will have the account of the other user trapped in the cache. This is bad.

I tried to use that cache in the template, but the performance problem comes from VIEW so it does not scroll.

The question is: my filter is very heavy and I have already made several adjustments to decrease. It gets to do an average of 180ms to 200ms in DEV and in production goes there for 300-400ms. This is a grotesque delay in my case.

When I used the Django cache for the URL or this cache_page was 8ms, it was beautiful. But nothing is perfect. I would like to know if anyone has any alternatives or how to work with these cases.

This is my setting in settings.py

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

django

asked by anonymous 14.09.2017 / 19:48

1 answer

How to sum a column of a file and view it with .plot (kind = 'bar')? How to change is_staff when I click on href?

score 1 · Accepted Answer

What you call a "problem" when using @cache_page(60 * 15) is not really a problem, it's only him doing his job correctly. I can not give a definitive solution to your case, however I can put some scenarios and you try to find what "matches" your problem. I will divide it into two main cases. Taking into account that you have a very heavy filter (for a query) you need to answer the following question:

Do all users have the same response for this query?

If your answer is yes, you may not need a cache on the page, but in the query itself, there are some ways to do it optimally in django, and if so, ".
If the answer is no, the "user" is probably part of this query that you set up. 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, however you will use the user id in some form of hash to identify that query (saved) corresponds to a given user. This problem is a little bigger because depending on the size of your application this cache (of django itself) can consume a lot of memory and you will still need to keep an eye on your server structure, since the query may already be cached in one of the two instances of the server and not 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.