清漆和ESI的性能如何? [英] Varnish and ESI, how is the performance?

问题描述

我想知道ESI模块的性能如何吗?我已经在网上阅读了一些帖子，其中说清漆的ESI性能实际上比真实的要慢.

Im wondering how the performance of th ESI module is nowadays? I've read some posts on the web that ESI performance on varnish were actually slower than the real thing.

说我有一个包含3500多个esi的页面，这将如何执行?是为这种用途设计的吗?

Say i had a page with over 3500 esi includes, how would this perform? is esi designed for such usage?

推荐答案

我们正在使用Varnish和ESI将子文档嵌入到JSON文档中.基本上，我们的应用服务器的响应如下所示:

We're using Varnish and ESI to embed sub-documents into JSON documents. Basically a response from our app-server looks like this:

[
  <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看起来像这样:

The included resources are complete and valid JSON responses on their own. The complete list of all stations is about 1070. So when the cache is cold and a complete station list is the first request varnish issues 1000 requests on our backend. When the cache is hot ab looks like this:

$ 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/sec看起来不太好，但要考虑文档的大小. 214066Kb/s会使1Gbit接口完全过饱和.

100 rec/sec doesn't look that good but consider the size of the document. 214066Kbytes/sec oversaturates a 1Gbit interface well.

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

A single request with warm cache ab (ab -c 1 -n 1 ...) shows 83ms/req.

后端本身是基于Redis的.我们在NewRelic中测量的平均响应时间为0.9ms [sic].重新启动Varnish后，第一个具有冷高速缓存的请求(ab -c 1 -n 1 ...)显示3158ms/rec.这意味着生成响应时需要使用Varnish，我们的后端每个ESI大约需要3毫秒.这是具有8个核心的标准核心i7披萨盒.我在满负荷的情况下进行了测量.这样，我们每月提供约150mio req的数据，命中率为0.9.这些数字确实表明，ESI包含文件是按顺序解析的.

The backend itself is redis based. We're measuring a mean response time of 0.9ms [sic] in NewRelic. After restarting Varnish the first request with a cold cache (ab -c 1 -n 1 ...) shows 3158ms/rec. This means it takes Varnish and our backend about 3ms per ESI include when generating the response. This is a standard core i7 pizza box with 8 cores. I measured this while being under full load. We're serving about 150mio req/month this way with a hitrate of 0.9. These numbers suggest indeed that the ESI-includes are resolved in serial.

在设计这样的系统时，您需要考虑的因素是:1)当缓存处于冷态时，在Varnish重新启动后，后端能够承担负载； 2)通常您的资源不会一次全部耗尽.如果是我们的电台，它们每隔一小时就会到期，但我们会在到期标头中添加最多120秒的随机值.

What you have to consider when designing a system like this is 1) that your backend is able to take the load after a Varnish restart when the cache is cold and 2) that usually your resources don't expire all at once. In case of our stations they expire every full hour but we're adding a random value of up to 120 seconds to the expiration header.

希望有帮助.

这篇关于清漆和ESI的性能如何?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！