20👍
We do a lot of component caching and not all of them are updated at the same time. So we set host and timestamp values in a universally included context processor. At the top of each template fragment we stick in:
<!-- component_name {{host}} {{timestamp}} -->
The component_name just makes it easy to do a View Source and search for that string.
All of our views that are object-detail pages define a context variable “page_object” and we have this at the top of the base.html template master:
<!-- {{page_object.class_id}} @ {{timestamp}} -->
class_id() is a method from a super class used by all of our primary content classes. It is just:
def class_id(self):
"%s.%s.%s" % (self.__class__._meta.app_label,
self.__class__.__name__, self.id)
If you load a page and any of the timestamps are more than few seconds old, it’s a pretty good bet that the component was cached.
16👍
Peter Rowells suggestion works well, but you don’t need a custom template context processor
for timestamps. You can simply use the template tag:
<!-- {% now "jS F Y H:i" %} -->
- Django: "order" a queryset based on a boolean field
- Django rest framework nested viewsets and routes
- Django raises MultiValueDictKeyError in File Upload
- How to install pygments on Ubuntu?
- Coverage in parallel for django tests
8👍
Mock the view, hit the page, and see if the mock was called. if it was not, the cache was used instead.
- Django global variable
- Django. Error message for login form
- Pycharm Django Debugging is really slow
- Registering Django system checks in AppConfig's ready() method
2👍
The reason you use caches is to improve performance. Test the performance by running a load test against your server. If the server’s performance matches your needs, then you are all set!
- How to combine django plus gevent the basics?
- Django HTML E-mail template doesn't load css in the e-mail
- How to populate user profile with django-allauth provider information?