Problem with Django Cache Page/URL

Asked

Viewed 74 times

0

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',
    }
}

1 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.

  • In my case the answer is yes, the query is the same for all users. The problem I found is that, for example, johnny cache is for python 2.7 and old verses of Django. In my case, I am using version 1.10 and python 3. Your answer is right, it is exactly what I need, cache in queryset, but it is difficult to find something that really works for my version. Do you have the path of stones there? Abs

  • 1

    I have a tip, I’ll need a little time to write and I’m kind of busy now. At the end of the day I’m in charge here!

  • 1

    A way that can help (not necessarily the best or most sophisticated) would be to perform this query as soon as the system starts and leaves it in a global variable of your system. If the content is totally static this solves, but if you wanted to give a "dynamism" solution you can configure a Celery to run an N function in N minutes that updates this global variable.

  • I was thinking about doing something similar. Maybe generate a json from the list and update it.. good think this will be the output by hour haha Thanks abs!

Browser other questions tagged

You are not signed in. Login or sign up in order to post.