【问题标题】:Failed requests by length in my ApacheBench load test result在我的 ApacheBench 负载测试结果中按长度失败的请求
【发布时间】:2010-12-03 11:52:38
【问题描述】:

我有一个 PHP 网站,Lighttpd。它还在 Centos 5 上使用 MySQL。我已经使用 Apache Bench (ab) 使用以下代码测试了我的 PHP。它导致了一些错误(失败的请求),表明其他长度不是正常的。我绝对确定我的 PHP 结果应该始终具有相同的确切长度。我查看了我的 Lighttpd 和 MySQL 日志以及错误日志,没有任何错误。

有没有什么方法可以准确地检查当结果有其他长度时 ab 得到了什么,或者有没有其他方法可以找出原因或“坏”结果是什么?

我需要知道这一点,因为我需要有 100% 的好结果。

-bash-3.2# ab -n 500 -c 200 http://domain.com/test/index.php
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking domain.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Finished 500 requests


Server Software:        lighttpd/1.4.20
Server Hostname:        domain.com
Server Port:            80

Document Path:          /test/index.php
Document Length:        15673 bytes

Concurrency Level:      200
Time taken for tests:   0.375862 seconds
Complete requests:      500
Failed requests:        499
   (Connect: 0, Length: 499, Exceptions: 0)
Write errors:           0
Total transferred:      7920671 bytes
HTML transferred:       7837000 bytes
Requests per second:    1330.28 [#/sec] (mean)
Time per request:       150.345 [ms] (mean)
Time per request:       0.752 [ms] (mean, across all concurrent requests)
Transfer rate:          20579.36 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   10   9.4      6      30
Processing:     0  113 133.5     16     342
Waiting:        0  111 134.3     12     341
Total:          0  123 138.9     16     370

Percentage of the requests served within a certain time (ms)
  50%     16
  66%    235
  75%    289
  80%    298
  90%    331
  95%    345
  98%    365
  99%    368
 100%    370 (longest request)

【问题讨论】:

    标签: php scalability lighttpd load-testing apachebench


    【解决方案1】:

    ab 假设所有响应都是相同的。它查看第一个响应的内容长度,然后将其他响应与该响应进行比较。

    来自手册页:

    Document Length
      This is the size in bytes of the first successfully returned document. 
      If the document length changes during  testing,  the  response  is 
      considered an error.
    

    因此,如果您的第一个请求包含以下数据:

    {"hostname":"nodecellar-1-dwfxd","serverip":"10.1.3.3"}
    

    接下来是:

    {"hostname":"nodecellar-1-dwfxd","serverip":"10.1.3.30"}
    

    ab 将因长度错误而失败,因为输出长了一个字符。

    【讨论】:

      【解决方案2】:

      使用-v 2 参数运行ab,表示详细级别2。这将转储响应标头。如果您的请求未使用分块编码,您将看到一个“Content-Length”标头,指示每个响应的大小。

      gw:~$ ab -n 1 -v 2 "http://whatever.com/"
      
      ...
      
      LOG: header received:
      HTTP/1.0 200 OK
      ...
      Content-Length: 1568399
      

      如果您的响应使用分块编码,则在传输结束之前不知道长度。通常分块编码只用于压缩响应,ApacheBench 默认不做压缩。

      如果它出于任何可能解释它的原因压缩响应;压缩长度取决于内容。

      您还可以使用curl -i--compress 选项来查看单个请求的响应标头(压缩和不压缩)。

      【讨论】:

      • 匿名用户的评论(被拒绝编辑): 注意:ab 要求所有回复的大小相同。如果您的输出大小可能会有所不同,您应该忽略“失败的请求”,因为ab 会认为它们失败。
      【解决方案3】:

      使用 tcpdump

      打开 2 个终端/shell 窗口或只使用屏幕。

      在第一个窗口中,使用 tcpdump 将来自/到您的 NIC (eth0) 的传输数据捕获到一个文件中:

      sudo tcpdump -s 9999 -i eth0 -w myfile.txt
      

      在第二个窗口中,启动你的 ab 命令:

      ab -n 500 -c 200 http://domain.com/test/index.php
      

      完成后,使用字符串和 grep 解析文件:

      strings myfile2.txt | grep -C 3 "200 OK"
      

      您应该能够通过观察或 grep'ing 结果从那里监控所有数据段。

      【讨论】:

      • 我在尝试 sudo tcpdump 时收到 'tcpdump: ioctl: No such device' 消息
      • 我按照你写的做了,结果如下: -- HTTP/1.0 200 OK Connection: close X-Powered-By: PHP/ 5.2.6 Content-type: text/html 我应该如何解释这个结果?
      • Tomaszs:您必须为正在运行的任何 *nix 操作系统更改 NIC 设备标识符。 Mac 上为 en0,Linux 上为 eth0 等。 HTTP/1.0 200 OK 表示 Web 服务器找到了请求的资源并返回了内容。页面成功!您只需阅读 myfile2.txt 的内容,即可了解故障出现在哪里。
      • strings 命令究竟做了什么?直接从文件所在目录grep有什么区别?
      猜你喜欢
      • 2010-10-09
      • 1970-01-01
      • 1970-01-01
      • 2016-09-04
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多