目前，我们有一项服务基于各种get参数创建XML页面。 随着参数数量的增加，不同组合的数量也越来越多，意味着我们的清漆缓存中的命中率已经下降。 我们增加了TTL，因此命中率有所增加，但我正在考虑以下想法：
我刚刚遇到了Edge Side Includes，我在想.. 如果我每次都生成包含50个元素的XML页面，我是否可以生成一个包含50个ESI的页面，然后将varnish组合成一个文档？
为什么要问50个ESI元素？因为每个XML元素本身都很容易被一个URL缓存，但是这些过滤器的组合会导致生成大量不同的完整XML文档。
因此，即使一个请求过滤掉前10个XML元素（因为它们没有向get参数确认），因为使用了ESI，每个元素都将从缓存中获取。
这对服务器有多重？这样做有意义吗？ ESI非常昂贵，在这种情况下它没有意义。
更新
首先，我们从未耗尽内存，Nuke为零。我们目前的命中/失败比率为0.4，ttl为4小时，这在我看来很糟糕......由于所有这些组合（国家，地区等）。更糟糕的是，tomcat已经达到了100％的利用率并且挂起了，而清漆保持了1-3％的研究。我的直觉是说有ESI涂层，并记住子文档将更多地保护tomcat并增加我们的容量。我们从来没有奇怪地使用Nuke项目，这意味着在缓存条目到期之前，它永远不会填充~1GB缓存。我敢肯定，如果我们缓存每个子文档，我们可能会达到内存限制并开始核心项目......但是varnish不使用某种最近最少使用的算法吗？
答案 0 :(得分：1)
对于有大量不同查询组合的一揽子缓存集合，通常不是最佳决策。有可能，某些查询组合的访问频率高于其他查询组合（例如，有很多搜索引擎优化组合的组合，或者您在您的网站上分发/共享链接到/有链接的组合，或者与您的用户更相关的组合），所以应该有选择地缓存这些。如果网址空间很大，那么仅缓存所有内容的问题在于，您可能会耗尽内存和核心资源，这些资源经常被访问以支持缓存不经常访问的内容。
每页的ESI包含没有限制，假设xml子文档的命中率非常高，您描述的方法是一个很好的策略。清单中的缓存命中非常轻量级，因此即使页面是50个缓存命中的组合，我认为与没有缓存相比它会表现得相当好。如果esi包含的子文档的命中率很低，并且每个页面上有大量的命中率，那么它将导致性能更差，而不是每次只有后端渲染子文档。我肯定会建议在以下场景中进行一些负载测试，以便您做出明智的决定：
这将很好地描述当您的命中率下降时性能将如何下降（它可能不是线性的，因此执行0％，50％，100％）并且还告诉您缓存可以提高多少缓存性能理论。对我来说，似乎最好的解决方案是esi的某种组合：包括定期访问的子文档的“工作集”中的片段，如果它们不在工作集中，则直接在后端呈现子文档。