☰

Apache Bench Varnish 长尾结果

tag-icon • tag-icon varnish
Apache Bench Varnish 长尾结果

我正在尝试在 Drupal 前面配置 Varnish，并且运行一些快速 Apache Bench 测试来查看我获得了什么样的改进。

我正在运行的具体 ab 命令是：ab -n 15000 -c 300 -k -H 'Accept-Encoding: gzip,deflate' www.mysite.tld/some-page

一旦我将并发度设置为高于 300 左右，我就会开始看到结果的真正长尾：

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      4
  75%      4
  80%      5
  90%      7
  95%     19
  98%     45
  99%    246
 100%   5016 (longest request)

随着并发性的增加，这种长尾现象会变得越来越糟，但似乎总是在 95％ 的连接之后发生（大约）。

对于相同的 ab 命令，但 c 位于 500：

  50%      1
  66%      1
  75%      1
  80%      2
  90%      5
  95%     22
  98%    365
  99%   5060
 100%   5061 (longest request)

对于 c=1000：

  50%      1
  66%      1
  75%      2
  80%      2
  90%      5
  95%     39
  98%   5061
  99%  27867
 100%  27885 (longest request)

我已更改以下 Varnish 设置：

thread_pool_add_delay      1 [milliseconds]
thread_pool_max            5000 [threads]
thread_pool_min            500 [threads]

varnish 机器和我用于测试的机器都在同一个子域中，实际上都是同一个 vmsphere 上的虚拟机。使用 siege 显示了类似的模式。

为什么会有这个长尾巴？我该如何去掉它？

编辑 我在基准测试时在 dmesg 中看到了这些消息：

[1469125.946204] TCP: Possible SYN flooding on port 80. Sending cookies.
[1469203.735802] TCP: Possible SYN flooding on port 80. Sending cookies.
[1469276.171367] TCP: Possible SYN flooding on port 80. Sending cookies.

我经常会看到有关套接字的有趣的事情：

$ netstat -ant | grep 80 | awk '{print $6}' | sort | uniq -c | sort -n
      1 TIME_WAIT
      2 LISTEN
    257 ESTABLISHED
    437 CLOSE_WAIT

在进行基准测试时，它通常会快速处理 0 - 13500 个请求，然后变得非常非常慢，有时只能处理到 15000 个。如果处理不成功，则连接将进入 CLOSE_WAIT 状态 - 可能是因为 Apache Bench 超时，因此套接字实际上并未关闭。但在等待时，通常会有一大堆套接字处于 ESTABLISHED 状态。

内核发回 syn cookies 时是否发生了什么事情，导致我的客户端超时并重试？

编辑2

虽然在实践中这可能是一个糟糕的想法，但我确实尝试禁用 syn cookies：

sysctl -n net.ipv4.tcp_syncookies = 0

这提供了明显更好的结果 - 对于 c=1000、n=25000，结果几乎与上面的 c=500、n=15000 相同。

但是，我也意识到，如果我每秒处理 3k 个请求，那么我实际上将非常接近达到出站网络管道的极限。因此，我可能会将我的网络参数恢复为默认值，而不必太担心我的基准测试结果。但我仍然非常好奇：a) 当两台机器都有足够的 CPU 时，为什么 syn cookies 会导致这种减速；b) 为什么即使禁用 syn cookies，我仍然看到类似的结果，只是 c 和 n 值更高。

答案1

我看不出您的基准测试结果有什么问题：

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      4
  75%      4
  80%      5
  90%      7
  95%     19
  98%     45
  99%    246
 100%   5016 (longest request)

这意味着所有请求的 90%（或 15,000 个请求中的 13,500 个）将在 7 毫秒内得到满足。

我假设剩余的 10% 是已传递到后端的请求（首次命中或更新）。如果请求必须传递到后端，则您不会对 Varnish 的性能进行基准测试，而是对后端（例如 Apache 和 mod_php）的性能进行基准测试。

答案2

这可能是因为您根本没有对 varnish 进行基准测试，而是对 CPU、操作系统的调度程序或线程模型，或者当多台机器使用大量 CPU 时对虚拟化平台进行基准测试。如果在几乎相同的硬件上运行，ab 和 varnish 可能会争夺相同的资源。varnish 的一位作者写了一篇关于对 varnish 进行基准测试的精彩文章，ab 很可能不是一个有用的工具： http://kly.no/posts/2012_04_19_Testing_Varnish.html

相关内容