No urls are shown as cached in the wagtail admin - terrible performance
weholt opened this issue · 6 comments
I've followed the instructions regarding wagtail-cache, and added the middleware (adding "wagtailcache.cache.UpdateCacheMiddleware" first and "wagtailcache.cache.FetchFromCacheMiddleware" last) as instructed, but none of my URLs are cached in production, and the response of my site is terrible. I see on the network monitoring in the developer panel in Chrome that the Django-part is to blame, taking up all of the loading time. My static and media content is served by CDN and is cached ok.
A couple things to consider:
- In the Django settings, ensure you have
CACHESset. Also make sureWAGTAIL_CACHE = True(this is the default) - Keep in mind that wagtail-cache will not cache pages if you are logged in to Wagtail. Be sure to test in a private tab, etc. where you are not logged in.
- Lastly, in the browser dev tools, inspect the request and look for an HTTP header named
X-Wagtail-Cache. If it is not present, something is definitely not configured. In all cases, this header should be present, and it will indicatehit,miss, orskip.skipis used when the page is intentionally not being cached.
I got something to work, but I'm not sure what it was in all the chaos. But I can see URLs in the cache in the admin now, and the performance is much better 1-2.5 sec per pageload, which is acceptable. I see the HTTP header; X-Wagtail-Cache: miss. Does that mean it has no cache entry? It didn't change when I reloaded the page several times either. But things are looking much better, and I did not know the cache only applied to non-authenticated users, so that's good to know.
PS! I see that I get a massive amount of SQL queries in the django-debug-toolbar, especially related to images. Will using cachalot or something similar have any effect on the number of queries? My site will be image-heavy so any optimization tips would be helpful. It probably didn't help that I have a rather big custom image model as well, because I need EXIF and IPTC metadata.
Anyhow, thanks a lot for all your help :-)
miss means it looked for that URL in the cache, but did not find it. Whenever there is a miss, it will store the result in the cache, so the next request to that URL should be a hit. If you keep getting repeated misses, then something on that page is preventing it from caching. Most likely this might be a CSRF token, if you have a form on the page, or something related to the Django session middleware if you are using session storage.
I'm not familiar with cachalot... but wagtail-cache will cache the entire page response, so images etc. have no effect on the performance of an already cached page (other than of course network bandwidth).
I would recommend reading "Notes about the request/response cycle" in the wagtail-cache docs to learn more how it works under the hood: https://docs.coderedcorp.com/wagtail-cache/getting_started/hooks.html#notes-about-the-request-response-cycle
It's the frontpage using the crx navbar with a search form, including CSRF token so that's probably it. I'm also checking to see if the current user is authenticated or not and toggle a login in or sign up link based on that. I'm not using search so I might remove that section, and find a different way to log users into the site. That might make the page cachable.
The login check shouldn't cause an issue... if the user is not logged in, the page will be cacheable, unless you are creating/setting a session. Logged in users will never be served cached pages by wagtail-cache.
The CRX search form in the navbar should not be creating a CSRF. It does not need it since it is using a GET request.
Closing this due to inactivity. Feel free to re-open if you are still experiencing the issue or have any new information. Thanks!