Any reason not to use USE_ETAGS with CommonMiddleware in Django?

The only reason I can think of is that calculating ETag's might be expensive. If pages change开发者_开发百科 very quickly, the browser's cache is likely to be invalidated by the ETag. In that case, calculating the ETag would be a waste of time. On the other hand, a giving a 304 response when possible minimizes the amount of time spent in transmission. What are some good guidelines for when ETag's are likely to be a net winner when implemented with Django's CommonMiddleware?

As with any caching mechanism, you will need to evaluate the trade-off between time spent manipulating the cache and bandwidth saved because of it.

As you say, if the response is changing often, ETags may not be very useful. ETags are a method for caching entire responses, so if the response changes often not much is actually being cached. However, I would guess that since ETags are in common use, browser implementations are resonably fast, and Django is probably fast enough too.

Perhaps there are other areas before the response that could benefit from caching with, for example, memcached.

Again, it will be beneficial to try profiling this with your real data rather than generalizing to "do or don't use it."

There are many ways to handle caching, and is often application specific, I propose in the first scenarios how you might consider using USE_ETAGS from django.middleware.common.CommonMiddleware:

1. Split your application between cacheable and non-cacheable gunicorn instances. Wire the site up with reverse-proxy. Then continue with,

2. Writing code that invalidates cache on model saves. As a next step,

3. Write own custom caching middleware.

I don't understand why you are looking for a reason not to do something. However your analysis is far from complete: conditional requests / 304 responses can actually make your application go significantly slower than it would if you strip the if-modified-since / if-none-match however they do keep search engines happy and are advantageous with server-server replication (e.g. on CDNs)

C.