17

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.

muhuk
  • 15,777
  • 9
  • 59
  • 98

4 Answers4

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.

Peter Rowell
  • 17,605
  • 2
  • 49
  • 65
  • Elegant solution. Can be automated as well. Thanks. – muhuk Dec 08 '08 at 07:11
  • Just for convenience sake, do you have the context processors you mentioned somewhere on djangosnippets.org or other site? – Matthew Dec 08 '08 at 17:22
  • 3
    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! – Peter Rowell Dec 08 '08 at 20:13
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" %} -->
Johannes
  • 1,558
  • 2
  • 9
  • 10
  • FWIW this broke the styling of my site in IE8 very badly when I added it as the first line of my template. Seems to be fine when it's inside the html tags. And I put it in html comment tags. Took a long time to figure out that was the cause of my css problems. – j_syk Aug 17 '11 at 23:48
  • I'm sorry to hear that, I'm afraid, I forgot about the comment tags. I fixed my solution entry accordingly. – Johannes Aug 22 '11 at 11:26
  • it just needs to be inside the declaration. just thought I'd post for future people reading this thread. but thanks, it is a simple and effective solution – j_syk Aug 22 '11 at 13:09
8

Mock the view, hit the page, and see if the mock was called. if it was not, the cache was used instead.

ironfroggy
  • 7,991
  • 7
  • 33
  • 44
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!

Ned Batchelder
  • 364,293
  • 75
  • 561
  • 662