我能想到的唯一原因是计算ETag's 可能很昂贵。如果页面变化很快，浏览器的缓存很可能会被ETag. 在这种情况下，计算ETag将是浪费时间。另一方面，304在可能的情况下给出响应可以最大限度地减少传输所花费的时间。ETag当使用 Django 实现 's 可能成为净赢家时，有哪些好的指导方针CommonMiddleware？
问问题
1068 次
3 回答
4
与任何缓存机制一样，您需要在操作缓存所花费的时间和因此节省的带宽之间进行权衡。
正如你所说，如果响应经常变化，ETags 可能不是很有用。ETag 是一种缓存整个响应的方法，因此如果响应经常更改，实际上不会缓存太多。但是，我猜想由于 ETag 很常见，浏览器的实现速度相当快，而且 Django 也可能足够快。
也许在响应之前还有其他区域可以从缓存中受益，例如 memcached。
同样，尝试使用您的真实数据分析它而不是概括为“使用或不使用它”将是有益的。
于 2013-06-30T18:33:32.757 回答
0
有很多方法可以处理缓存，并且通常是特定于应用程序的，我在第一个场景中建议您如何考虑使用USE_ETAGSfrom django.middleware.common.CommonMiddleware：
在可缓存和不可缓存的 gunicorn 实例之间拆分您的应用程序。使用反向代理连接站点。然后继续，
编写使模型保存上的缓存无效的代码。作为下一步，
编写自己的自定义缓存中间件。
于 2014-03-23T22:26:06.660 回答
-2
我不明白你为什么要找一个不做某事的理由。但是您的分析远未完成：条件请求/ 304 响应实际上可以使您的应用程序运行速度明显慢于如果您去除 if-modified-since / if-none-match 但是它们确实让搜索引擎满意并且有优势服务器-服务器复制（例如在 CDN 上）
C。
于 2010-05-05T13:21:03.563 回答