Deck detail page is slow and uncached

[vorpal-buildbot]

Reported on Discord by bakert#2193

[bakert]

Over 50 page loads taking more than a minute in the last three hours.

[bakert]

In terms of reported slow pages this page is now dominating all others at something like 100:1 ratio.

In an attempt to speed up the site in general I tried to slow down bots with f48e8dd. But making this page faster will surely have a good effect.

[silasary]

If you disable redis (config.json,: redis_enabled), does this get better or worse?

[silasary]

At a guess, it'll get worse.

Looking at the decks that are being reported, they tend to fall into two categories.

• Decks that are active and/or have just finished a run, hit by humans.
• Decks that are absolutely ancient, hit by robots.

Tournament/imported decks are not appearing anywhere near as frequently.

This tends to imply that the redis cache is working well, for the decks that are actually loaded into cache, and the slow pages are tending towards decks that aren't in redis.

[bakert]

Deck detail page is no longer dominating slow pages as it was in June. Various perf improvements have changed a lot of the variables since then.

/, /seasons/all/, /seasons/all/* and deck detail pages make up a lot of it, though.

It occurs to me that we treat deck detail page as uncacheable because we show different views to admin/owner than we do to others when the deck is in a run BUT (a) the vast majority decks are not in a run, and (b) that's only two different views of the page not one-per-user or anything like that.

Can we complicate our caching code to cache two versions of a page based on a switch and determine the value of that switch at cache-decision-time?

[bakert]

It's definitely easy to add can_view as part of the cache key based on is_admin but is_owner seems tougher as there's not a very sensible way to access that kind of info from cache.py nor pass it in. Needs a bit of thought.

[bakert]

While it would be great to cache based on a key of (url, locale, is_admin_or_owner) it's non-trivial and not the most pressing perf concern right now so backlogging. We should do this at some point though.