我的ApacheBench負載測試結果中的長度失敗請求

我在PHP，Lighttpd中有一個網站。它還在Centos 5上使用MySQL。我已經用Apache Bench（ab）的代碼測試了我的PHP。它導致了一些錯誤（失敗的請求），表明其他長度比正常。我絕對相信我的PHP結果應該始終具有相同的確切長度。我檢查了我的Lighttpd和MySQL日誌和錯誤日誌，並且沒有任何錯誤。我的ApacheBench負載測試結果中的長度失敗請求

有沒有什麼辦法來檢查什麼時候結果有其他的長度或有任何其他方式找出的原因是什麼或什麼是「壞」的結果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)

來源

2009-10-02 Tomasz Smykowski

與-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選項來查看具有和不具有壓縮的單個請求的響應標頭。

來源

2010-07-03 01:11:09

+27

**匿名用戶評論（拒絕編輯）：**注意：'ab'預計所有回覆的大小相等。如果有可能你的輸出大小不同，你應該忽略「失敗的請求」，因爲「ab」會認爲它們失敗。 – Anne 2011-12-12 22:14:21

使用的tcpdump

打開數量2終端/殼窗口或只使用屏幕。

在第一個窗口，使用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"

你應該能夠monito從目前的所有數據段通過眼球或grep'ing結果。

來源

2009-10-03 00:12:46

我得到 'tcpdump的：IOCTL：沒有這樣的設備' 嘗試消息時須藤tcpdump的 – 2009-10-03 08:32:07

我你寫做了什麼，這是結果： - <！ - 結束Quantcast標籤 - > HTTP /1.0 200 OK 連接方式：關閉 X-Powered-by：PHP/5.2.6 內容類型：text/html 我應該如何解釋這個結果？ – 2009-10-03 17:21:02

Tomaszs：您將不得不更改您正在運行的任何* nix OS的NIC設備標識符。 Mac上的en0，Linux上的eth0等。 HTTP/1.0 200 OK表示Web服務器找到了請求的資源和返回的內容。頁面成功！您只需閱讀myfile2.txt的內容即可查看故障發生的位置。 – 2009-10-06 22:02:02

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將失敗，長度錯誤，因爲輸出長一個字符。

來源

2016-06-29 11:57:30 Tom

我的ApacheBench負載測試結果中的長度失敗請求

回答

相關問題