0

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

我刚刚遇到 Edge Side Includes 并在想.. 如果我每次生成包含 50 个元素的 XML 页面，我是否可以生成一个包含 50 个 ESI 的页面，然后清漆将合并到一个文档中？

为什么要问 50 个 ESI 元素？因为每个 XML 元素本身很容易被一个 URL 缓存，但是过滤器的组合会导致生成大量不同的完整 XML 文档。

因此，即使一个请求过滤掉了前 10 个 XML 元素（因为它们没有确认获取参数），因为使用了 ESI，每个元素都将从缓存中获取。

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

更新

首先，我们从未耗尽内存，Nuke 为零。我们目前的命中/未命中率为 0.4，ttl 为 4 小时，在我看来这很糟糕……由于所有这些组合（国家、地区等）。更糟糕的是，tomcat 已达到 100% 的利用率并挂起，而 varnish 则停留在 1-3% 的研究中。我的直觉说，用清漆缝合 ESI，并记住子文档将更好地保护 tomcat 并增加我们的容量。我们从来没有奇怪地 Nuke 项目，这意味着在缓存条目过期之前它永远不会填充 ~ 1GB 缓存。我敢肯定，如果我们缓存每个子文档，我们可能会达到内存限制并开始核对项目......但是清漆不使用某种最近最少使用的算法吗？

4

1 回答 1

1

对于有大量不同查询组合的缓存集合，通常不是最好的决定。很可能，某些查询组合的访问频率比其他查询组合要高得多（例如，有很多 SEO 汁液的组合，或者您在您的网站上分发/共享链接/具有链接的组合，或者与您的用户更相关的组合)，因此应该有选择地缓存这些内容。仅将所有内容缓存为长 ttl 的问题是，如果 url 空间很大，您可能会耗尽内存和经常访问的核资源，以支持缓存不经常访问的内容。

每页包含的 ESI 没有限制，假设 xml 子文档的命中率非常高，您描述的方法是一个很好的策略。varnish 中的缓存命中非常轻量级，因此即使一个页面由 50 个缓存命中组合而成，我认为与没有缓存相比，它的性能会非常好。如果 esi 包含的子文档的命中率很低，并且每个页面上都有大量的子文档，那么这将导致比每次只让后端渲染子文档的性能更差。我肯定会建议对以下场景进行一些负载测试，以便您做出明智的决定：

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

这将很好地说明随着命中率的下降，性能将如何下降（它可能不是线性的，因此执行 0%、50%、100%），并且还告诉您理论上缓存可以提高多少性能。在我看来，最好的解决方案似乎是 esi 的某种组合：包括定期访问的子文档的“工作集”中的片段，如果子文档不在工作集中，则直接在后端呈现子文档。

于 2013-07-17T18:04:28.473 回答