有什么理由不在 Django 中将 USE_ETAGS 与 CommonMiddleware 一起使用？
我能想到的唯一原因是计算 ETag 可能会很昂贵。如果页面变化非常快，浏览器的缓存很可能会被 ETag 失效。在这种情况下，计算ETag将是浪费时间。另一方面，在可能的情况下给出 304 响应可以最大限度地减少传输所花费的时间。当使用 Django 的 CommonMiddleware 实现时，ETag 可能成为最终的赢家，有哪些好的指导原则？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
与任何缓存机制一样，您需要评估操作缓存所花费的时间和因此节省的带宽之间的权衡。
正如您所说，如果响应经常变化，ETag 可能不是很有用。 ETag 是一种缓存整个响应的方法，因此如果响应经常发生变化，实际上不会缓存太多内容。然而，我猜想，由于 ETag 很常用，浏览器实现速度相当快，Django 可能也足够快。
也许在响应之前还有其他区域可以从缓存中受益，例如 memcached。
同样，尝试使用真实数据进行分析而不是概括为“使用或不使用它”将是有益的。
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."
处理缓存的方法有很多，并且通常是特定于应用程序的，我在第一个场景中建议您如何考虑使用
django.middleware.common.CommonMiddleware中的USE_ETAGS：编写使模型保存时的缓存无效的代码。下一步，
编写自己的自定义缓存中间件。
There are many ways to handle caching, and is often application specific, I propose in the first scenarios how you might consider using
USE_ETAGSfromdjango.middleware.common.CommonMiddleware:Split your application between cacheable and non-cacheable gunicorn instances. Wire the site up with reverse-proxy. Then continue with,
Writing code that invalidates cache on model saves. As a next step,
Write own custom caching middleware.
我不明白你为什么要找理由不做某事。然而，您的分析还远未完成：条件请求/ 304 响应实际上会使您的应用程序运行速度明显慢于剥离 if-modified-since / if-none-match 的速度，但是它们确实让搜索引擎满意，并且有利于服务器到服务器复制（例如在 CDN 上）
C.
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.