Is there a way to be sure that a page is coming from cache on a production server and on the development server as well?
The solution shouldn't involve caching middleware because not every project uses them. Though the solution itself might be a middleware.
Just checking if the data is stale is not a very safe testing method IMO.
-
Mock the view, hit the page, and see if the mock was called. if it was not, the cache was used instead.
-
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!
-
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.
muhuk : Elegant solution. Can be automated as well. Thanks.Matthew : Just for convenience sake, do you have the context processors you mentioned somewhere on djangosnippets.org or other site?Peter Rowell : Adding a context processor is easy! 1. Create a file, e.g. my_context.py. 2. Create a function that takes a request object, e.g. my_context(request). 3. Return a dict of fun stuff available to all templates. 4. Add "my_context.my_context" to TEMPLATE_CONTEXT_PROCESSORS in settings.py. 5. Profit!
0 comments:
Post a Comment