边缘限制包含在一页内？

Question

目前我们有一个基于各种获取参数创建XML页面的服务。 随着参数数量的增加，不同组合的数量也在增加，这意味着我们的清漆缓存中的命中率已经下降。 我们已经增加了TTL，因此命中率有所增加，但是我正在玩弄以下想法：

我刚刚遇到了Edge Side Includes，并且正在想.. 如果我生成的XML页面包含50元素，我可以生成一个包含50个ESI（s）的页面，然后将这些清漆合并成一个文档？

为什么选择50个ESI元素？由于每个XML元素本身都很容易被一个URL缓存，但是这些过滤器的组合会导致生成大量不同的完整XML文档。因此，即使有一个请求过滤掉了前10个XML元素（因为它们没有向get params确认），因为使用ESIs，每个元素都将从缓存中获取。

这将在服务器上有多沉重？这样做有意义吗？ ESI是非常昂贵的，在这种情况下，它是没有意义的。

更新

---

首先，我们从来没有用完的内存和核弹是零。我们目前的命中率为0,4，时间为4小时，这在我看来是糟糕的...由于所有这些组合（国家，地区等）。更糟糕的是，tomcat的使用率已经达到100％，而清漆停留在研究的1-3％。我的直觉告诉我们，用清漆缝合ESI，记住这些子文档将更好地保护tomcat并提高我们的容量。我们从来不需要奇怪地使用Nuke项目，这意味着在高速缓存条目到期之前永远不会填满〜1GB高速缓存。我确定如果我们缓存每个子文档，我们可能会达到内存限制，并开始nuking项目...但不清漆使用某种最近最少使用的算法？

Answer 1

通常不是覆盖缓存集合的最佳决策，其中有大量不同的查询组合。很有可能，某些查询组合的访问次数比其他查询组合要多得多（例如，有很多SEO果汁的组合，或者在您的网站上发布/共享链接到/有链接的组合，或者与您的用户更相关），所以这些应该有选择地缓存。将所有内容缓存很长时间的问题在于，如果url空间很大，那么您可能会耗尽内存和核查经常访问的资源，以便缓存不常访问的内容。

对于每页包含的ESI没有限制，假设xml子文档的命中率非常高，您描述的方法是一个很好的策略。清漆中的高速缓存命中非常轻量级，因此即使页面是由50个高速缓存命中组成的复合体，我认为与没有高速缓存相比，它的性能会非常好。如果包含子文档在内的esi的命中率很低，并且每页上都有大量的文档，则会导致性能下降，而不仅仅是每次都有后端呈现子文档。我肯定会推荐在下列情况下进行一些负载测试，以便您可以作出明智的决定：

1. 没有缓存，后端每次都会呈现子文档。
2. ESI将子文档呈现为片段，0％缓存命中。
3. ESI将子文档呈现为片段，50％缓存命中。
4. ESI将子文档呈现为片段，100％缓存命中。

这将给出一个关于性能如何降低你的命中率下降（它可能不是线性的，因此做0％，50％，100％），并告诉你有多少缓存可以提高理论上的表现。对我来说，最好的解决方案似乎是esi的一些组合：包括片段在经常访问的子文档的“工作集”中，并且如果子文档不在工作集中，则直接在子系统上呈现子文档。