清漆和ESI，性能如何

我想知道现在ESI模块的性能如何？我在网上读过一些帖子，说 ESI 在清漆上的性能实际上比真实的东西慢。

假设我有一个包含 3500 多个 esi 的页面，这将如何执行？ ESI 是否专为此类用途而设计？

我们使用 Varnish 和 ESI 将子文档嵌入到 JSON 文档中。基本上，来自我们的应用程序服务器的响应如下所示：

[
  <esi:include src="/station/best_of_80s" />,
  <esi:include src="/station/herrmerktradio" />,
  <esi:include src="/station/bluesclub" />,
  <esi:include src="/station/jazzloft" />,
  <esi:include src="/station/jahfari" />,
  <esi:include src="/station/maximix" />,
  <esi:include src="/station/ondalatina" />,
  <esi:include src="/station/deepgroove" />,
  <esi:include src="/station/germanyfm" />,
  <esi:include src="/station/alternativeworld" />
]

包含的资源本身就是完整且有效的 JSON 响应。所有车站的完整列表约为1070。因此，当缓存是冷的并且完整的站列表是第一个请求时，清漆在我们的后端发出 1000 个请求。当缓存是热的ab时，看起来像这样：

$ ab -c 100 -n 1000 http://127.0.0.1/stations
[...]
Document Path:          /stations
Document Length:        2207910 bytes
Concurrency Level:      100
Time taken for tests:   10.075 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      2208412000 bytes
HTML transferred:       2207910000 bytes
Requests per second:    99.26 [#/sec] (mean)
Time per request:       1007.470 [ms] (mean)
Time per request:       10.075 [ms] (mean, across all concurrent requests)
Transfer rate:          214066.18 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1   11   7.3      9      37
Processing:   466  971  97.4    951    1226
Waiting:        0   20  16.6     12      86
Total:        471  982  98.0    960    1230
Percentage of the requests served within a certain time (ms)
  50%    960
  66%    985
  75%    986
  80%    988
  90%   1141
  95%   1163
  98%   1221
  99%   1229
 100%   1230 (longest request)
$

100 rec/秒看起来不太好，但请考虑文档的大小。 214066KB/秒使 1Gbit 接口过饱和。

具有热缓存 ab （ab -c 1 -n 1 ...）的单个请求显示 83ms/req。

后端本身是基于 Redis 的。我们在NewRelic中测量的平均响应时间为0.9ms [原文如此]。重新启动 Varnish 后，第一个带有冷缓存的请求（ab -c 1 -n 1 ...）显示 3158ms/rec。这意味着在生成响应时，每个 ESI 需要 Varnish 和我们的后端大约 3 毫秒。这是一个标准的酷睿i7披萨盒，有8个核心。我在满负荷下测量了这一点。我们以这种方式提供大约 150mio req/月的服务，命中率为 0.9。这些数字确实表明 ESI 包含是按顺序解析的。

在设计这样的系统时，您必须考虑的是 1）当缓存冷时，您的后端能够在 Varnish 重新启动后承担负载，以及 2）通常您的资源不会立即全部过期。对于我们的电台，它们每整小时过期一次，但我们会在过期标头中添加最多 120 秒的随机值。

希望有帮助。

这不是第一手资料，但我被引导相信 Varnish 当前的 ESI 实现序列化包括请求; 也就是说，它们不是并发的。

如果是这样的话，在您提到的情况下，性能确实很糟糕。

我会尝试让有第一手经验的人发表评论。

并行 ESI 请求在清漆的 **商业** 版本中可用：https://www.varnish-software.com/plus/parallel-esi/。片段请求的并行性质显然使由多个片段组成的页面的组装速度更快。

（这将是一个评论，但我没有足够的声誉来做到这一点）

相关内容

最新更新

热门标签：