我的 ApacheBench 负载测试结果中按长度排列的失败请求
我有一个 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)
I have a website in PHP, Lighttpd. It uses also MySQL on Centos 5. I've tested my PHP with code below with Apache Bench (ab). It resulted in some errors (Failed Requests) indicating other length than normal. I'm absolutely sure that my PHP result should always have the same exact length. I've reviewed my Lighttpd and MySQL logs and error logs and don't have any errors there.
Is there any way to check exactly what ab gets when result has other length or is there any other way to find out what is the cause or what is the "bad" result?
I need to know that because I need to have 100% good results.
-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 gt; 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)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
使用
-v 2
参数运行ab
,这意味着详细级别为 2。这将转储响应标头。如果您的请求未使用分块编码,您将看到一个“Content-Length”标头,指示每个响应的大小。如果您的响应使用分块编码,则在传输结束之前不知道长度。通常分块编码仅用于压缩响应,ApacheBench 默认情况下不进行压缩。
如果它出于任何可以解释的原因压缩响应;压缩长度取决于内容。
您还可以使用
curl -i
和--compress
选项来查看单个请求的响应标头(压缩或不压缩)。Run
ab
with the-v 2
parameter, meaning verbosity level 2. This will dump the response headers. If your requests are not using chunked encoding, you will see a "Content-Length" header indicating the size of each response.If your responses use chunked encoding, then the length is not known until the transfer ends. Usually chunked encoding is only used for compressed responses, and ApacheBench doesn't do compression by default.
If it is compressing the responses for whatever reason that might explain it; the compressed length depends on the content.
You can also use
curl -i
and the--compress
option to see the response headers to a single request with and without compression.使用 tcpdump
打开 2 个终端/shell 窗口或仅使用 screen。
在第一个窗口中,使用 tcpdump 将 NIC (eth0) 的传输数据捕获到文件:
在第二个窗口中,启动 ab 命令:
全部完成后,使用字符串和 grep 解析文件:
您应该能够通过观察或查询结果来监控所有数据段。
Use tcpdump
Open qty 2 terminal/shell windows or just use screen.
In the first window, use tcpdump to capture transmission data from/to your NIC (eth0) to a file:
In the second window, fire off your ab command:
When that's all done, parse the file with strings and grep:
You should be able to monitor all the data segments from there by eyeballing or grep'ing the results.
ab 假设所有响应都是相同的。它查看第一个响应的内容长度,然后与其他响应进行比较。
从手册页来看:
因此,如果您的第一个请求包含以下数据:
下一个请求是:
ab 将因长度错误而失败,因为输出多了一个字符。
ab assumes that all responses are the same. It looks at the content-length of the first response, and then compares others to that.
From the man page:
So if your first request contains following data:
And the next one is:
ab will fail with a Length error, since the output is one character longer.
这是动态页面的问题,发生这种情况是因为
Content-Length
HTTP 标头在请求之间可能有所不同。当对此类页面使用ab
时,您需要使用-l
选项。This is an issue with dynamic pages, it happens because the
Content-Length
HTTP header can vary between the requests. When usingab
with such pages you need to use the-l
option.