清漆和ESI，性能如何？

Question

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

假设我有一个包含超过3500个esi的页面，这将如何执行？esi是为这种用途而设计的吗？

Answer 1

我们使用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个。因此，当缓存是冷的，并且一个完整的站点列表是第一个请求时，varnish在我们的后端发出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)
$ 

100rec/sec看起来不是很好，但考虑到文档的大小。214066K字节/秒可以很好地使1Gbit接口过饱和。

具有热缓存的单个请求ab (ab -c 1 -n 1 ...)显示83毫秒/请求。

后端本身是基于redis的。我们在NewRelic中测量的平均响应时间为0.9ms sic。重启后，使用冷缓存(ab -c 1 -n 1 ...)对第一个请求进行Varnish显示3158ms/rec。这意味着在生成响应时，它需要Varnish和我们的后端，每个ESI包含大约3ms。这是一个标准的核心i7披萨盒，有8个核心。我是在满载的情况下测量的。我们以这种方式每月提供约150mio请求，命中率为0.9。这些数字确实表明ESI-includes是按顺序解析的。

在设计这样的系统时，你需要考虑的是: 1)当缓存处于冷状态时，你的后端能够在Varnish重启后承担负载；2)通常情况下，你的资源不会同时过期。对于我们的站点，它们每满一小时就过期一次，但我们在过期报头中添加了一个最多120秒的随机值。

希望这能有所帮助。

Answer 2

这不是第一手的，但我相信Varnish当前的ESI实现序列化了包括请求；即，它们不是并发的。

如果是这样的话，在你提到的情况下，它的性能确实很差。

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

Answer 3

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

(这将是一个评论，但我没有足够的声誉来做这件事)