Apache での ab パフォーマンステスト結果を分析する

私はパフォーマンステストを行うために常に Loadrunner を使用してきました。 Loadrunner は、実際には非常に重いパフォーマンステストツールです。機能が充実しており、非常に優れた肉切り包丁です。

ページで単純なパフォーマンステストを実行するだけの場合は、Loadruner を使用することは適切な選択ではありません。

そこで、試しに小さなナイフを探しました。このナイフは本当に軽くて鋭いです。ここでは、皆さんの参考のために、AB テストのプロセスに関する私の理解の一部を記録します。

Baiduのホームページを例に挙げてみましょう。まず、knife が必要です。つまり、Apache をインストールします。インターネット上にチュートリアルがたくさんあるので、繰り返しません。この記事では、テストのために MacBook に付属している ab コマンドを使用します。

テストシナリオ: 10 人のユーザーをシミュレートし、Baidu ホームページに対して合計 100 件のリクエストを開始します。

テストコマンド: ab -n 100 -c 10 https://www.baidu.com/index.html

この記事では、主に ab のテストレポートを分析します。ab の使用方法については、別の日に新しい投稿で説明します。

テストレポート:

私の理解を一行ずつ説明させてください。以下のメモはオンライン資料を参考にしていますが、内容はすべて私自身の理解に基づいて手書きされています。私自身の理解を加えることで、読者の理解が深まることを願っています。

ボゴン:~ タン$ ab -n 100 -c 10 https://www.baidu.com/index.html

これは ApacheBench バージョン 2.3 です <$Revision: 1706008 $>

著作権 1996 Adam Twiss、Zeus Technology Ltd、http://www.zeustech.net/

Apache Software Foundation にライセンス供与されています (http://www.apache.org/)

//以上為apache的版本信息，與本次測試無關

www.baidu.com のベンチマーク (しばらくお待ちください).....完了

//以上內容顯示測試完成度，本次測試發起請求數量較少，完成較快，無中間過程顯示。在請求數量很多時會分行顯示當前完成數量。

サーバーソフトウェア: bfe/1.0.8.14 //被測試的服務器所用的軟件信息，這里使用的是百度自己開發的反向代理Baidu Front End,類似nginx。

サーバーホスト名: www.baidu.com //被測主機名

サーバーポート: 443 //被測主機的服務端口號，一般http請求的默認端口號是80，https默認使用443端口

SSL/TLS プロトコル: TLSv1.2、ECDHE-RSA-AES128-GCM-SHA256、2048、128 //加密協議

ドキュメントパス: /index.html //請求的具體文件

ドキュメントの長さ: 227 バイト//請求的文件index.html大小

同時実行レベル: 10 //并發級別，也就是并發數，請求中－c參數指定的數量

/本次測試總共花費的時間

完了したリクエスト: 100 //本次測試總共發起的請求數量

//失敗的請求數量。因網絡原因或服務器性能原因，發起的請求并不一定全部成功，通過該數值和Complete requests相除可以計算請求的失敗率，作為測試結果的重要參考。

//總共傳輸的數據量，指的是ab從被測服務器接收到的總數據量，包括index.html的文本內容和請求頭信息。

転送された HTML: 22700 バイト//從服務器接收到的index.html文件的總大小，等于Document Length＊Complete requests＝227bytes＊100＝22700 bytes

1 秒あたりのリクエスト数: 91.50 [#/sec] (平均) //平均(mean)每秒完成的請求數：QPS，這是一個平均值，等于Complete requests/Time taken for tests=100/1.093=91.50

//從用戶角度看，完成一個請求所需要的時間（因用戶數量不止一個，服務器完成10個請求，平均每個用戶才接收到一個完整的返回，所以該值是下一項數值的10倍。）

//服務器完成一個請求的時間。

転送速度: 92.32 [Kbytes/sec] 受信//網絡傳輸速度。對于大文件的請求測試，這個值很容易成為系統瓶頸所在。要確定該值是不是瓶頸，需要了解客戶端和被測服務器之間的網絡情況，包括網絡帶寬和網卡速度等信息。

接続時間 (ミリ秒)

最小平均[+/- 標準偏差] 中央値最大値

コネクト: 47 74 12.9 74 106

処理: 9 32 20.2 32 106

待機中: 9 29 19.1 27 98

合計: 66 106 20.8 106 195

//這幾行組成的表格主要是針對響應時間也就是第一個Time per request進行細分和統計。一個請求的響應時間可以分成網絡鏈接（Connect），系統處理（Processing）和等待（Waiting）三個部分。表中min表示最小值；mean表示平均值；[+/-sd]表示標準差（Standard Deviation），也稱均方差（mean square error），這個概念在中學的數學課上學過，表示數據的離散程度，數值越大表示數據越分散，系統響應時間越不穩定。 median表示中位數； max當然就是表示最大值了。

//需要注意的是表中的Total并不等于前三行數據相加，因為前三行的數據并不是在同一個請求中采集到的，可能某個請求的網絡延遲最短，但是系統處理時間又是最長的呢。所以Total是從整個請求所需要的時間的角度來統計的。這里可以看到最慢的一個請求花費了195ms，這個數據可以在下面的表中得到驗證。

一定時間内に処理されたリクエストの割合（ミリ秒）

50% 106

66% 109

75% 111

80% 114

90% 118

95% 154

98% 176

99% 195

100% 195 (最長リクエスト)

//這個表第一行表示有50%的請求都是在106ms內完成的，可以看到這個值是比較接近平均系統響應時間（第一個Time per request: 109.287 [ms] (mean)）