有什么理由不在Django中使用USE_ETAGS和CommonMiddleware？

Question

我能想到的唯一原因是计算ETag可能很贵。如果页面变化非常快，则ETag可能会使浏览器的缓存失效。在这种情况下，计算ETag将浪费时间。另一方面，在可能的情况下给出304响应可以最小化传输所花费的时间。当使用Django的ETag实现CommonMiddleware时，{{1}}可能成为净胜利者有哪些好的指导方针？

Answer 1

与任何缓存机制一样，您需要评估操作缓存所花费的时间与因此而节省的带宽之间的权衡。

正如您所说，如果响应经常发生变化，那么ETag可能不是很有用。 ETag是一种缓存整个响应的方法，因此如果响应更改通常不会实际缓存。但是，我猜想由于ETag是常用的，浏览器实现速度相当快，而且Django也可能足够快。

也许在响应之前还有其他区域可以从缓存中受益，例如，memcached。

同样，尝试使用您的真实数据进行分析而不是概括为“使用或不使用它”将是有益的。

Answer 2

有很多方法可以处理缓存，并且通常是特定于应用程序的，我在第一个方案中建议您如何考虑使用USE_ETAGS中的django.middleware.common.CommonMiddleware：

1. 在可缓存和不可缓存的gunicorn实例之间拆分应用程序。使用反向代理连接站点。然后继续，

2. 编写使模型保存缓存无效的代码。下一步，

3. 编写自己的自定义缓存中间件。

Answer 3

我不明白你为什么要寻找不做某事的理由。但是你的分析还远远没有完成：条件请求/ 304响应实际上可以使你的应用程序变得比你删除if-modified-since / if-none-match时慢得多，但它们确实让搜索引擎保持开心并且有利于服务器 - 服务器复制（例如在CDN上）

下进行。