Cache the footer_api template based on version for one minute #4524
Conversation
This is something that should increase the speed of our responses on the most popular versions. It will make it so that users who update their versions might not see the footer change in under a minute, but I think we can probably put up with that for the hopeful performance benefits.
|
This is mainly here for a fallback during the Azure migration, but I think it probably makes sense to push out before, if it makes sense. I mostly want to see what happens when we do it :) |
This is similar to #4524, where resolving a ton of URL's for versions is time consuming. This limits that by only listing the stable version, if it exists, for featured projects on our homepage
| {% load cache %} | ||
|
|
||
| {# Vary the cache on the version #} | ||
| {% cache 60 footer-html version.pk %} |
There was a problem hiding this comment.
What about adding versions.count as a key also here and increasing the time of the cache a little more?
There was a problem hiding this comment.
I actually realized this isn't specific to the version, but to the project as a whole, so that should be even better.
There was a problem hiding this comment.
The VCS block actually will change by page, so I need to think through this a bit more.
|
Need to think about this a bit more granularly. Currently we're linking to the specific page that a user hit, so caching this actually will not work 100%. |
ericholscher
added
the
PR: work in progress
| @@ -11,6 +15,7 @@ | |||
| <div class="rst-other-versions"> | |||
| {% endif %} | |||
|
|
|||
| {% cache 60 footer_html_versions project.pk %} | |||
There was a problem hiding this comment.
I think we should cache the sections "Versions" and "Languages" in different blocks. Adding/Removing a language won't invalidate the cache otherwise.
Also, why footer_html_version? Should be just versions the right variable to check? And, I think it should be versions.count at least
There was a problem hiding this comment.
Also, this wasn't caught on review of the front page, but whenever cache tag is used, we need to account for the user language as a separate argument as well. Without this, the language of the first user to cache this will be used.
|
Closing this, as I don't think it's an issue we're currently facing, and had some issues. |
This is something that should increase the speed of our responses on the most popular versions.
It will make it so that users who update their versions might not see the footer change in under a minute,
but I think we can probably put up with that for the hopeful performance benefits.
I think that increasing this also makes a lot of sense, if we build a way to bust the cache. I think generating this fresh on every pageview for the most part doesn't make much sense.