Apacheベンチ-概要

パフォーマンステストは、ビジネスの成功に不可欠であることが証明されています。パフォーマンスの低いサイトは経済的な損失に直面するだけでなく、時には法的影響をもたらすこともあります。

購入、オンラインテストの受験、請求書の支払いなどの重要なオンラインインタラクションで、パフォーマンスの低い信頼性の低いサイトに我慢したい人はいません。インターネットは非常に広く利用されているため、選択肢の幅は計り知れません。顧客を獲得するよりも顧客を失う方が簡単であり、パフォーマンスは重要なゲームチェンジャーです。

負荷テストツールの必要性

負荷テストツールの必要性を理解できれば、それを使用する理由と動機がわかります。有名なビジネスサイトの中には、多数の訪問者を獲得したときに深刻なダウンタイムに見舞われたものがあります。 EコマースWebサイトは、広告キャンペーンに多額の投資を行いますが、負荷テストには投資しません。そのため、マーケティングがトラフィックをもたらす場合、最適なシステムパフォーマンスを確保できません。

負荷テストを無視するもう1つのよく知られた例は、WordPress Webサイトでの「接続の確立エラー」です。したがって、運用環境に展開する前にWebサイトまたはアプリケーションをロードテストすることをお勧めします。より詳細なテストを実行する前に、プロジェクトのベストケースシナリオをすばやく確立しておくと便利です。

Apache Benchとは何ですか？

Apache Bench（ab）は、HTTP（Hypertext Transfer Protocol）Webサーバーのベンチマークを行うためのApache組織のツールです。 Apache Webサーバーのパフォーマンスを測定するように設計されていますが、同様に優れた他のWebサーバーのテストにも使用できます。このツールを使用すると、Webサーバーが1秒間に処理できるリクエストの数をすばやく知ることができます。

Apache Benchの機能

Apache Benchの重要な機能と制限を見てみましょう。機能と制限は以下のとおりです-

オープンソースソフトウェアであるため、無料で入手できます。
これは、単純なコマンドラインコンピュータープログラムです。
プラットフォームに依存しないツールです。これは、Linux/UnixでもWindowsサーバーでも同様に起動できることを意味します。
HTTPまたはHTTPSのWebサーバーのみの負荷およびパフォーマンステストを実行できます。
拡張可能ではありません。

Apache Benchは、並行性レベル（-cフラグで指定）に関係なく、オペレーティングシステムスレッドを1つだけ使用します。したがって、大容量サーバーのベンチマークを行う場合、Apache Benchの単一インスタンス自体がボトルネックになる可能性があります。サーバーに複数のプロセッサコアがある場合、ターゲットURLを完全に飽和させるには、Apache Benchの追加インスタンスを並行して使用することをお勧めします。

予防措置

Apache Benchには、テストの実行中に特定の間隔で同時実行性を高めるためのディレクティブがないことに注意する必要があります。したがって、abを使用して負荷テストを実行することは、サービス拒否（DOS）攻撃と同等です。長期間にわたって高負荷テストを行う場合は、VPSサービスプロバイダーに通知して事前の許可を取得することをお勧めします。適切な時間間隔を割り当てるか、負荷テストタスクのためにノードを移動します。

第二に、VPS（テストノードになる）からApache Benchを学習するためだけに第三者のWebサイトを継続的に長時間テストしている場合、VPSパブリックIPが第三者のWebサイトによってブロックされる可能性がほとんどありません永久に。その場合、同じIPを使用してそのWebサイトに接続することはできません。ただし、将来Webサイトに本当に接続したい場合、唯一の解決策は、ターゲットWebサイトのシステム管理者に問い合わせるか、VPSサービスプロバイダーの助けを借りて、異なるIPを使用してサーバーの新しいインスタンスを作成することです。

警告してきましたが、このチュートリアルのすべてのテストは十分に安全であり、システム管理者が一般に「システム乱用」プラクティスと呼ぶものから外れていることを保証します。

Apacheベンチ-環境設定

この章では、VPSでApache Benchの環境を設定する方法を説明します。

システム要件

メモリ-128 MB
ディスク容量-最小要件なし
オペレーティングシステム-最小要件なし

Apache Benchのインストール

Apache Benchはスタンドアロンアプリケーションであり、Apache Webサーバーのインストールに依存しません。以下は、Apache Benchをインストールする2段階のプロセスです。

ステップ1 *-パッケージデータベースを更新します。

# apt-get update

端末コマンドの前の記号＃は、rootユーザーがそのコマンドを発行していることを意味することに注意してください。

ステップ2 *-Apache Benchにアクセスするには、apache2 utilsパッケージをインストールします。

# apt-get install apache2-utils

Apache Benchがインストールされました。同じVPSでホストされているWebアプリケーションをテストする場合は、Apache Webサーバーのみをインストールするだけで十分です-

# apt-get install apache2

ApacheユーティリティであるApache Benchは、Apache Webサーバーのインストール時に自動的にインストールされます。

Apache Benchインストールの検証

Apache Benchのインストールを確認する方法を見てみましょう。次のコードは、インストールの検証に役立ちます-

# ab -V

出力

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

上記のターミナル出力が表示されたら、Apache Benchが正常にインストールされたことを意味します。

特権Sudoユーザーの作成

安全性の観点から、システム管理者がrootとして作業する代わりにsudoユーザーを作成することをお勧めします。私たちは目的のために、テストという名前のテストユーザーを作成します-

# useradd -m -d/home/test -g sudo test

新しいユーザーのパスワードを設定しましょう-

# passwd test

システムは、ユーザーテスト用の新しいパスワードの入力を求めます。本番サーバーに展開するのではなく、テストするだけなので、簡単なパスワードを入力できます。通常、sudoコマンドは、sudoユーザーパスワードの入力を求めます。プロセスが煩雑になるため、複雑なパスワードを使用しないことをお勧めします。

出力

Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

Apache.org Webサイトのテスト

このセクションでは、Apache.org Webサイトをテストします。最初にsudoユーザーテストに切り替えましょう-

# su test

まず、Apache組織のWebサイトhttps://www.apache.org/をテストします。私たちは最初にコマンドを実行し、次に出力を理解します-

$ ab -n 100 -c 10 https://www.apache.org/

ここで、*-n *は、ベンチマークセッションで実行するリクエストの数です。デフォルトでは、通常、非代表的なベンチマーク結果につながる単一の要求を実行します。

また、*-c *は同時実行性であり、一度に実行する複数のリクエストの数を示します。デフォルトは一度に1つのリクエストです。

そのため、このテストでは、Apache BenchはApache組織サーバーに対して同時実行10で100件のリクエストを行います。

出力

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.apache.org (be patient).....done

Server Software:        Apache/2.4.7
Server Hostname:        www.apache.org
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256

Document Path:         /
Document Length:        58769 bytes

Concurrency Level:      10
Time taken for tests:   1.004 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      5911100 bytes
HTML transferred:       5876900 bytes
Requests per second:    99.56 [#/sec] (mean)
Time per request:       100.444 [ms] (mean)
Time per request:       10.044 [ms] (mean, across all concurrent requests)
Transfer rate:          5747.06 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       39   46  30.9     41     263
Processing:    37   40  21.7     38     255
Waiting:       12   15  21.7     13     230
Total:         77   86  37.5     79     301

Percentage of the requests served within a certain time (ms)
  50%     79
  66%     79
  75%     80
  80%     80
  90%     82
  95%     84
  98%    296
  99%    301
 100%    301 (longest request)

私たちの最初のテストを実行すると、このコマンドの使用パターンは次のように簡単に認識できます-

# ab [options .....]  URL

どこで、

ab -Apache Benchコマンド
options -実行する特定のタスクのフラグ
URL -テストするパスURL

出力値を理解する

abによって返されるさまざまな出力値を理解するには、さまざまなメトリックを理解する必要があります。ここにリストがあります-

サーバーソフトウェア-最初に成功した戻りのHTTPヘッダーで返されるWebサーバーの名前です。
サーバーのホスト名-コマンドラインで指定されたDNSまたはIPアドレスです。
サーバーポート-abが接続しているポートです。コマンドラインでポートが指定されていない場合、httpの場合は80、httpsの場合は443がデフォルトになります。
* SSL/TLSプロトコル*-これは、クライアントとサーバーの間でネゴシエートされるプロトコルパラメーターです。これは、SSLが使用されている場合にのみ出力されます。
ドキュメントパス-これは、コマンドライン文字列から解析されたリクエストURIです。
ドキュメント長-最初に正常に返されたドキュメントのバイト単位のサイズです。テスト中にドキュメントの長さが変わると、応答はエラーと見なされます。
同時実行レベル-これは、テスト中に使用された同時クライアント（Webブラウザーに相当）の数です。
テストの所要時間-これは、最初のソケット接続が作成されてから最後の応答が受信されるまでにかかった時間です。
Complete Requests -受信した成功した応答の数。
失敗したリクエスト-失敗と見なされたリクエストの数。数がゼロよりも大きい場合、接続、読み取り、不適切なコンテンツの長さ、または例外のために失敗した要求の数を示す別の行が印刷されます。
合計転送-サーバーから受信した合計バイト数。この数は、基本的には回線を介して送信されたバイト数です。
* HTML転送*-サーバーから受信したドキュメントバイトの総数。この数には、HTTPヘッダーで受信したバイトは含まれません
Requests per second -これは1秒あたりのリクエスト数です。この値は、リクエスト数を合計所要時間で割った結果です。
リクエストごとの時間-リクエストごとの平均時間。最初の値は式の同時実行*所要時間* 1000/完了で計算され、2番目の値は式の所要時間* 1000/完了で計算されます
転送レート-数式totalread/1024/timetakenによって計算された転送レート。

負荷テスト出力の迅速な分析

abコマンドからの出力値の見出しについて学んだので、最初のテストの出力値を分析して理解してみましょう-

Apache組織は独自のWebサーバーソフトウェアを使用しています-Apache（バージョン2.4.7）
サーバーはhttpsのためにポート443でリッスンしています。 httpだったら、80（デフォルト）だったでしょう。
転送されるデータの合計は、100リクエストで58769バイトです。
テストは1.004秒で完了しました。失敗したリクエストはありません。
秒あたりのリクエスト数-99.56。これはかなり良い数と考えられています。
要求ごとの時間-100.444ミリ秒（10の同時要求の場合）。したがって、すべてのリクエストで、100.444 ms/10 = 10.044 msです。
転送速度-1338.39 [Kバイト/秒]を受信しました。
接続時間の統計では、多くのリクエストが数秒間待機する必要があることがわかります。これは、リクエストを待機キューに入れているApache Webサーバーが原因である可能性があります。

最初のテストでは、別のサーバーでホストされているアプリケーション（つまり、www.apache.org）をテストしました。チュートリアルの後半では、abテストを実行するサーバーと同じサーバーでホストされているサンプルWebアプリケーションをテストします。これは、学習とデモンストレーションを簡単にするためです。理想的には、正確な測定のためにホストノードとテストノードは異なる必要があります。

abをよりよく学習するには、このチュートリアルを進めるときに、出力値がさまざまなケースでどのように変化するかを比較して観察する必要があります。

Apacheベンチの出力のプロット

ここでは、関連する結果をプロットして、リクエストの数が増えるにつれてサーバーがどれだけの時間を要するかを確認します。そのために、前のコマンドで -g オプションを追加し、その後にab出力データが保存されるファイル名（ここではout.data）を追加します-

$ ab -n 100 -c 10 -g out.data https://www.apache.org/

プロットを作成する前に、 out.data を見てみましょう-

$ less out.data

出力

starttime       seconds ctime   dtime   ttime   wait
Tue May 30 12:11:37 2017        1496160697      40      38      77      13
Tue May 30 12:11:37 2017        1496160697      42      38      79      13
Tue May 30 12:11:37 2017        1496160697      41      38      80      13
...

*out.data* ファイルの列ヘッダーを理解しましょう-

starttime -これは、コールが開始された日時です。
seconds -starttimeと同じですが、Unixタイムスタンプ形式です（date -d @ 1496160697はstarttime出力を返します）。
ctime -これは接続時間です。
dtime -これは処理時間です。
ttime -これは合計時間です（ctimeとdtimeの合計、数学的にはttime = ctime + dtime）。
wait -これは待機時間です。

これらの複数のアイテムが互いにどのように関連しているかを視覚的に視覚化するには、次の画像を見てください-

複数のアイテム

端末で作業している場合、またはグラフィックが利用できない場合は、 gnuplot が最適なオプションです。次の手順を実行することで、すぐに理解できます。

gnuplotをインストールして起動します-

$ sudo apt-get install gnuplot
$ gnuplot

出力

G N U P L O T
Version 4.6 patchlevel 6    last modified September 2014
Build System: Linux x86_64

Copyright (C) 1986-1993, 1998, 2004, 2007-2014
Thomas Williams, Colin Kelley and many others

gnuplot home:     http://www.gnuplot.info
faq, bugs, etc:   type "help FAQ"
immediate help:   type "help"  (plot window: hit 'h')

Terminal type set to 'qt'
gnuplot>

端末上で作業しており、グラフィックが利用できないと想定しているため、端末自体にASCIIで出力するダム端末を選択できます。これは、このクイックツールでプロットがどのように見えるかを知るのに役立ちます。ここで、ASCIIプロット用の端末を準備しましょう。

gnuplot> set terminal dumb

出力

Terminal type set to 'dumb'
Options are 'feed  size 79, 24'

これで、gnuplotターミナルはASCIIプロットの準備ができたので、 out.data ファイルからデータをプロットしましょう-

gnuplot> plot "out.data" using 9  w l

出力 *

  1400 ++-----+------+-----+------+------+------+------+-----+------+-----++
       +      +      +     +      +      +      +"out.data" using 9* **** *+
       |                                                                   |
  1200 ++                      * *******************************************
       |     ****************** *|
  1000 ++   * ++
       | *|
       |    * |
   800 ++ *++
       |   * |
       | *|
   600 ++  * ++
       | *|
       |   * |
   400 ++ *++
       |   * |
   200 ++ *++
       |   * |
       +****  +      +     +      +      +      +      +     +      +      +
     0 ++-----+------+-----+------+------+------+------+-----+------+-----++
       0      10     20    30     40     50     60     70    80     90    100

要求の数に対して、9列目から合計時間（ミリ秒単位）のttimeをプロットしました。最初の10個のリクエストでは、合計時間が約100ミリ秒でしたが、次の30個のリクエスト（10 ^ th ^から40 ^ th ^）では、1100ミリ秒に増加しました。プロットは、 out.data によって異なる必要があります。

サンプルアプリケーションのテスト

前の章では、サードパーティのWebサイトをテストするためのApacheベンチの基本的な使用法を理解しました。このセクションでは、このツールを使用して、独自のサーバーでWebアプリケーションをテストします。チュートリアルを可能な限り自己完結型に保つために、デモ用にPythonアプリケーションをインストールすることを選択しました。専門レベルに応じて、PHPやRubyなどの他の言語を選択できます。

Pythonをインストールする

通常、PythonはデフォルトでLinuxサーバーにインストールされます。

Bottle Frameworkのインストールと簡単なアプリケーションの作成

Bottleは、Webアプリケーションを作成するためにpythonで書かれたマイクロフレームワークであり、pipはpythonパッケージマネージャーです。ターミナルに次のコマンドを入力して、ボトルをインストールします-

$ sudo apt-get install python-pip
$ sudo pip install bottle

ここで、小さなボトルアプリケーションを作成しましょう。そのために、ディレクトリを作成し、その中に移動します-

$ mkdir webapp
$ cd webapp

webappディレクトリ内に新しいPythonスクリプト app.py を作成します-

$ vim app.py

さて、app.pyファイルに次のコードを書きます-

from bottle import Bottle, run

app = Bottle()

@app.route('/')
@app.route('/hello')
def hello():
   return "Hello World!"

run(app, host = 'localhost', port = 8080)

上記の行を追加したら、ファイルを保存して閉じます。ファイルを保存したら、Pythonスクリプトを実行してアプリケーションを起動できます-

$ python app.py

出力

Bottle v0.12.7 server starting up (using WSGIRefServer())...
Listening on http://localhost:8080/
Hit Ctrl-C to quit.

この出力は、アプリケーションがホスト http：//localhost のローカルマシンで実行され、ポート 8080 でリッスンしていることを示しています。

アプリがHTTPリクエストに適切に応答しているかどうかを確認しましょう。このターミナルは、Bottleアプリケーションのサービスを終了しないと入力を受け取れないため、別のターミナルでVPSにログインする必要があります。別の端末でVPSにログインした後、新しい端末で次のコードを入力して、アプリケーションに移動できます。

$ lynx http://localhost:8080/

Lynxはコマンドラインブラウザーであり、通常はDebianやUbuntuなどのさまざまなLinuxディストリビューションにデフォルトでインストールされます。次の出力が表示される場合、アプリが正常に機能していることを意味します。

出力

Lynx

上記の出力が表示された場合、それはアプリケーションが稼働しており、テストの準備ができていることを意味します。

開発用Webサーバーを使用したアプリケーションのテスト

abにはバグがあり、ローカルホストでアプリケーションをテストできないことに注意してください。したがって、app.pyファイルでホストをlocalhostから127.0.0.1に変更します。したがって、ファイルは次のように変更されます-

from bottle import Bottle, run

app = Bottle()

@app.route('/')
@app.route('/hello')
def hello():
   return "Hello World!"

run(app, host = '127.0.0.1', port = 8080)

lynxコマンドを実行したのと同じ端末で次のコマンドを入力して、アプリをテストしましょう-

$ ab -n 100 -c 10  http://127.0.0.1:8080/hello

出力

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        WSGIServer/0.1
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:         /hello
Document Length:        12 bytes

Concurrency Level:      10
Time taken for tests:   0.203 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      16500 bytes
HTML transferred:       1200 bytes
Requests per second:    493.78 [#/sec] (mean)
Time per request:       20.252 [ms] (mean)
Time per request:       2.025 [ms] (mean, across all concurrent requests)
Transfer rate:          79.56 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       0
Processing:     1    6  28.2      2     202
Waiting:        1    6  28.2      2     202
Total:          1    6  28.2      2     202

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      2
  75%      2
  80%      2
  90%      2
  95%      2
  98%    202
  99%    202
 100%    202 (longest request)

最初の端末の出力は次のようになります（100回）-

...
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET/hello HTTP/1.0" 200 12
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET/hello HTTP/1.0" 200 12
127.0.0.1 - - [10/Jun/2017 04:30:26] "GET/hello HTTP/1.0" 200 12
...

最初のテストと比較して、ab結果のさまざまな値がどのように変化したかを観察できます。

マルチスレッドWebサーバーを使用したアプリケーションのテスト

abの以前のテストでは、BottleフレームワークにバンドルされているデフォルトのWebサーバーを使用しました。

次に、シングルスレッドのデフォルトWebサーバーをマルチスレッドサーバーに変更します。したがって、 cherrypy や gunicorn などのマルチスレッドWebサーバーライブラリをインストールし、Bottleに使用するように指示してみましょう。ここでは、デモンストレーションの目的でgunicornを選択しました（他のgunicornも選択できます）-

$  sudo apt-get install gunicorn

そして、ファイルを変更します。つまり、デフォルトのWebサーバーからgunicornに変更します-

...
run(server = 'gunicorn'...)
...

2番目のターミナルでアプリをテストしてみましょう。

$ ab -n 100 -c 10  http://127.0.0.1:8080/hello

出力

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        gunicorn/19.0.0
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:         /hello
Document Length:        12 bytes

Concurrency Level:      10
Time taken for tests:   0.031 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      17200 bytes
HTML transferred:       1200 bytes
Requests per second:    3252.77 [#/sec] (mean)
Time per request:       3.074 [ms] (mean)
Time per request:       0.307 [ms] (mean, across all concurrent requests)
Transfer rate:          546.36 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.9      0       4
Processing:     1    2   0.7      3       4
Waiting:        0    2   0.8      2       3
Total:          2    3   0.6      3       5
WARNING: The median and mean for the initial connection time are not within a normal
        deviation These results are probably not that reliable.
WARNING: The median and mean for the processing time are not within a normal deviation
        These results are probably not that reliable.

Percentage of the requests served within a certain time (ms)
  50%      3
  66%      3
  75%      3
  80%      3
  90%      4
  95%      5
  98%      5
  99%      5
 100%      5 (longest request)

1秒あたりのリクエスト数が493から3252にどのように増加したかを確認します。これは、gunicornがPythonアプリの実稼働サーバーとして適していることを意味します。

複数のURLを同時にテストする

この章では、複数のURLを同時にテストする方法を学びます。そのためには、アプリケーションファイルapp.pyを編集して2つのURLを含める必要があります-

from bottle import Bottle, run

app = Bottle()

@app.route('/')
@app.route('/hello1')
def hello():
   return "Hello World! It is first URL."

@app.route('/hello2')
def hello():
   return "Hello World! It is second URL."

run(app,server = 'gunicorn',host = '127.0.0.1', port = 8080)

単純なシェルスクリプトの作成

これを行うには、複数のab呼び出しを使用してシェルスクリプトを作成します。ファイルtest.shを作成し、それに次の行を追加します-

ab -n 100 -c 10 http://127.0.0.1:8080/hello1
ab -n 100 -c 10 http://127.0.0.1:8080/hello2

上記の行を追加したら、ファイルを保存して閉じます。ファイルを実行可能にします-

chmod u+x test.sh

スクリプトを実行しましょう-

./test.sh

繰り返しと明確化の目的を避けるために、ab出力の関連部分のみを示し、以下のように、どの部分が省略されたかをドットで示します。

出力

.
.
.
Document Path:         /hello1
Document Length:        732 bytes

Concurrency Level:      10
Time taken for tests:   0.040 seconds
Complete requests:      100
Failed requests:        0
Non-2xx responses:      100
Total transferred:      90000 bytes
HTML transferred:       73200 bytes
Requests per second:    2496.13 [#/sec] (mean)
Time per request:       4.006 [ms] (mean)
Time per request:       0.401 [ms] (mean, across all concurrent requests)
Transfer rate:          2193.87 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.8      0       3
Processing:     1    3   1.0      4       5
Waiting:        0    3   1.2      4       4
Total:          1    4   0.6      4       5
WARNING: The median and mean for the processing time are not within a normal deviation
        These results are probably not that reliable.
.
.
.

Apacheベンチの出力をファイルに保存するシェルスクリプト

複数のab呼び出しでシェルスクリプトを作成することにより、Apache Bench出力をファイルに保存できます。各行の最後に*＆; *を配置すると、コマンドがバックグラウンドで実行され、次のコマンドの実行が開始されます。 <filename>を使用して、各URLのファイルに出力をリダイレクトすることもできます。たとえば、ファイルtest.shは、変更後は次のようになります-

$ ab -n 100 -c 10 http://127.0.0.1:8080/hello1 > test1.txt &
$ ab -n 100 -c 10 http://127.0.0.1:8080/hello2 > test2.txt &

ここで、 test1.txt および test2.txt は、出力データを保存するファイルです。

上記のスクリプトが、それぞれのURLのab出力を含む2つのファイルtest1.txtおよびtest2.txtを作成したことを確認できます-

$ ls -l

出力

...
-rw-r--r-- 1 root root  5225 May 30 12:11 out.data
-rwxr--r-- 1 root root   118 Jun 10 12:24 test.sh
-rw-r--r-- 1 root root  1291 Jun 10 12:31 test1.txt
-rwxr--r-- 1 root root    91 Jun 10 13:22 test2.sh
-rw-r--r-- 1 root root  1291 Jun 10 12:31 test2.txt
...

警戒状況

abを使用している間、警告なしで失敗したテストについて警告する必要があります。たとえば、間違ったURLをチェックすると、次のようなメッセージが表示される場合があります（ここでポートを意図的に変更しました）。

$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:805/

出力

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done

Server Software:
Server Hostname:        127.0.0.1
Server Port:            805

Document Path:         /
Document Length:        Variable

Concurrency Level:      10
Time taken for tests:   0.002 seconds
Complete requests:      100
Failed requests:        150
   (Connect: 0, Receive: 100, Length: 0, Exceptions: 50)
Keep-Alive requests:    0
Total transferred:      0 bytes
HTML transferred:       0 bytes
Requests per second:    44984.26 [#/sec] (mean)
Time per request:       0.222 [ms] (mean)
Time per request:       0.022 [ms] (mean, across all concurrent requests)
Transfer rate:          0.00 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     0    0   0.2      0       0
Waiting:        0    0   0.0      0       0
Total:          0    0   0.2      0       0

Percentage of the requests served within a certain time (ms)
  50%      0
  66%      0
  75%      0
  80%      0
  90%      0
  95%      0
  98%      0
  99%      0
 100%      0 (longest request)

動的ページのテストの準備

この章では、動的ページのテストに必要な準備を理解します。サーバー側の動的なWebページは、サーバー側のスクリプトを処理するアプリケーションサーバーによって構築が制御されるWebページです。 Apacheベンチは、サーバー側の動的Webページのロードテストのみ可能です。

同時実行レベルとリクエストの総数

同時実行レベルは、リクエストの総数よりも低くする必要があります。

$ ab -l -r -n 30 -c 80 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

出力

ab: Cannot use concurrency level greater than total number of requests
Usage: ab [options] [http[s]://]hostname[:port]/path

フラグの使用

このセクションでは、abコマンドでいくつかの重要なフラグを使用する方法について説明します。用語、オプション、フラグを同じ意味で使用します。

詳細-v

詳細オプションを使用して、失敗したリクエストが複数存在する場合に分析およびデバッグできます。負荷テストの失敗の一般的な兆候は、テストが非常に高速に終了し、1秒あたりの要求値として適切な数値が得られることです。しかし、それは間違ったベンチマークになります。成功または失敗を識別するには、*-v 2 *オプションを使用して、各応答の本文とヘッダーを端末出力にダンプします。次のコマンドは、ユースケースを示しています-

$ ab -n 1 -v 2 http://www.generic-example-URL.com/

出力

LOG: header received:
HTTP/1.0 200 OK
…
Content-Length: 2548687

もちろん、エラーが発生した場合に変数の応答をテストしたり、200以外のHTTPコードを返したりする場合は、*-l *オプションを使用した長さチェックを無視する必要があります。以降の章でweb2pyアプリケーションを起動するときに、200以外のHTTPがすぐに表示されます。

キープアライブ-k

クライアントがHTTP要求を送信すると、サーバーへの接続が行われ、サーバーが応答を送信し、要求を送信した後に接続が閉じられます。このサイクルは、リクエストごとに続きます。ただし、キープアライブ設定（永続的接続とも呼ばれます）では、クライアントは複数の要求と応答を容易にするために、基礎となるTCP接続を開いたままにします。これにより、他の方法では存在する低速でコストのかかる接続初期化時間がなくなります。

可変ドキュメント長-l

Webページが可変長の場合、オプション -l を使用する必要があります。応答の長さが一定でない場合、Apache Benchはエラーを報告しません。これは、動的ページに役立ちます。

オプション-rの使用

エラーの受信時にabが終了しないようにするにはどうすればよいですか？オプション -r を使用する必要があります。このオプションがないと、リクエストがソケットエラーにヒットするとすぐにテストが中断する可能性があります。ただし、このオプションを使用すると、失敗したエラーの見出しにエラーが報告されますが、テストは最後まで続行されます。

オプション-Hの使用

このオプションは、任意のヘッダー行を追加するために使用されます。引数は通常、コロンで区切られたフィールドと値のペアを含む有効なヘッダー行の形式です（つまり、「Accept-Encoding：zip/zop; 8bit」）。

オプション-Cの使用

次のセクションでは、Cookie値を使用するオプション（ -C オプション）と組み合わせて上記のオプションを使用する方法を詳細に学習します。 -Cオプションは通常、 name = value ペアの形式です。このフィールドは繰り返すことができます。

ApacheベンチでのセッションCookieの使用

ApacheベンチでCookieを使用する方法を理解するには、Cookieを設定しようとするWebページが必要です。非常に良い例は、Python Webフレームワークであるweb2pyアプリケーションです。

web2pyのインストール

別のpythonアプリweb2pyをすばやくインストールします。使用方法の詳細については、link：/web2py/web2py_framework_overview [Web2py Framework Overview]をご覧ください。

通常、PythonはUbuntuおよびDebianサーバーにデフォルトでインストールされます。したがって、web2pyを正常に実行するための1つの要件がすでに満たされています。

ただし、unzipパッケージをインストールして、ダウンロードするzipファイルからweb2pyのソースファイルを抽出する必要があります-

$ sudo apt-get update
$ sudo apt-get install unzip

プロジェクトのWebサイトからweb2pyフレームワークを取得しましょう。これをホームフォルダにダウンロードします-

$cd ~
$ wget http://www.web2py.com/examples/static/web2py_src.zip

これで、ダウンロードしたファイルを解凍して内部に移動できます-

$ unzip web2py_src.zip
$ cd web2py

web2pyを実行するために、インストールする必要はありません。あなたがweb2pyディレクトリの中にいると、次のコマンドを入力してそれを実行することができます-

$python web2py.py

すべてが成功すると、次の出力が表示され、管理UIのパスワードを選択するように求められます-

web2py Web Framework
Created by Massimo Di Pierro, Copyright 2007-2017
Version 2.14.6-stable+timestamp.2016.05.10.00.21.47
Database drivers available: sqlite3, imaplib, pymysql, pg8000
WARNING:web2py:GUI not available because Tk library is not installed
choose a password:

please visit:
        http://127.0.0.1:8000/
use "kill -SIGTERM 23904" to shutdown the web2py server

ただし、起動されたWebインターフェースはローカルマシンでのみアクセス可能であるという事実に注意する必要があります。

出力から、Webサーバーを停止するには、インスタントターミナルで「CTRL-C」と入力する必要があることを理解できます。一方、同じVPSに関連する他の端末でweb2pyサーバーを停止するには、コマンドkill -SIGTERM <PID>を挿入できます。ここで、<PID>はweb2pyサーバーのプロセスIDです。この場合は23904。

web2pyからのセッションCookie

ログインしたユーザーのみがページにアクセスでき、ログインページから直接アクセスできない場合は、*-C *フラグを使用できます。このフラグは、abコマンドのCookieを定義します。ただし、有効なセッションからセッションID Cookieの値を取得する必要があります。入手方法は？さまざまなオンラインチュートリアルで、Chrome（またはMozilla）ブラウザー開発者ツールを紹介します。ただし、テストケースでは、アプリケーションはコマンドラインでのみ使用できるため、lynxブラウザーを使用して値を取得します。

最初にセッションのCookie値を取得します。別の端末を開き、次のコマンドを入力します-

$ lynx http://127.0.0.1:8000/

上記のコマンドに対する応答として、lynxは、下の画像に示すようにweb2pyサーバーからのCookieを受け入れる許可を求めます。

web2pyからのセッションCookie

*y* を入力してCookieを受け入れる前に、Cookieの値を書き留めます。 これで、ターミナルは次の画像のようになります–ターミナルのウェブサイト！

ターミナルのウェブサイト

Cookie値を取得したら、abテストを実行します。そのためには、3番目の端末を開く必要があります（下の画像を参照）-

Cookie値

さて、3番目の端末で-Cフラグを使用しましょう-

$ ab -n 100 -c 10 -C session_name = 127.0.0.1-643dad04-3c34  http://127.0.0.1:8000/

出力

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:         /
Document Length:        66 bytes

Concurrency Level:      10
Time taken for tests:   0.051 seconds
Complete requests:      100
Failed requests:        0
Non-2xx responses:      100
Total transferred:      27700 bytes
HTML transferred:       6600 bytes
Requests per second:    1968.12 [#/sec] (mean)
Time per request:       5.081 [ms] (mean)
Time per request:       0.508 [ms] (mean, across all concurrent requests)
Transfer rate:          532.39 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   0.9      2       4
Processing:     0    3   0.9      3       5
Waiting:        0    2   1.1      2       4
Total:          4    5   0.7      5       7

Percentage of the requests served within a certain time (ms)
  50%      5
  66%      5
  75%      5
  80%      6
  90%      6
  95%      6
  98%      7
  99%      7
 100%      7 (longest request)

上記の出力から、いくつかの点に注意してください。まず、web2pyはhttps://launchpad.net/rocket[Rocket] Webサーバーを使用します。また、前述の出力の見出しに加えて、「Non-2xx応答」も取得していることに注意してください。一般に、Httpプロトコルは応答コードを使用して要求に応答し、200の範囲内のすべては「大丈夫」を意味し、残りは何らかの問題に対応します。たとえば、400は404 File Not Foundなどのリソース関連のエラーです。 500はサーバーエラーに対応します。この例では、-Cオプションを使用している場合を除き、どこにもエラーはありません。既に説明したように、-lオプションを使用して抑制できます。

管理ページの確認

このセクションでは、管理ページを確認する方法を理解します。比較のために、web2pyアプリケーションの別のURLをテストしましょう-

$ ab -n 100 -c 10 session_name = 127.0.0.1-643dad04-3c34  http://127.0.0.1:8000/admin

出力

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:         /admin
Document Length:        8840 bytes

Concurrency Level:      10
Time taken for tests:   2.077 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      926700 bytes
HTML transferred:       884000 bytes
Requests per second:    48.14 [#/sec] (mean)
Time per request:       207.749 [ms] (mean)
Time per request:       20.775 [ms] (mean, across all concurrent requests)
Transfer rate:          435.61 [Kbytes/sec] received

Connection Times (ms)
          min  mean[+/-sd] median   max
Connect:        0    1   3.2      0      12
Processing:    62  204  52.2    199     400
Waiting:       61  203  52.0    199     400
Total:         62  205  54.3    199     411

Percentage of the requests served within a certain time (ms)
  50%    199
  66%    211
  75%    220
  80%    226
  90%    264
  95%    349
  98%    381
  99%    411
 100%    411 (longest request)

特に、 http：//127.0.0.1：8000/ および http：//127.0.0.1：8000/admin のセクション「接続時間」および「処理されたリクエストの割合」の各統計に注意してください。。大きな違いがあります。

制限時間オプションの使用

一般に、Timelimitオプションは扱いにくいものです。 manual of abからこれを理解しましょう。

-t timelimit
Maximum number of seconds to spend for benchmarking. This implies a -n 50000 internally.
Use this to benchmark the server within a fixed total amount of time.
Per default there is no timelimit.

このオプションでテストを実行しましょう。出力を通過した後の観察に注意します-

$ ab -n 100 -c 10 -t 60   http://127.0.0.1:8000/

出力

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 5000 requests
Completed 10000 requests
Completed 15000 requests
Completed 20000 requests
Completed 25000 requests
Completed 30000 requests
Completed 35000 requests
Completed 40000 requests
Completed 45000 requests
Completed 50000 requests
Finished 50000 requests


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:         /
Document Length:        66 bytes

Concurrency Level:      10
Time taken for tests:   22.547 seconds
Complete requests:      50000
Failed requests:        0
Non-2xx responses:      50000
Total transferred:      13850000 bytes
HTML transferred:       3300000 bytes
Requests per second:    2217.61 [#/sec] (mean)
Time per request:       4.509 [ms] (mean)
Time per request:       0.451 [ms] (mean, across all concurrent requests)
Transfer rate:          599.88 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   0.8      2       8
Processing:     0    2   3.2      2     218
Waiting:        0    2   3.2      2     218
Total:          2    4   3.1      4     220

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      4
  80%      5
  90%      5
  95%      5
  98%      7
  99%      8
 100%    220 (longest request)

出力は、このオプションが -n オプションで指定されたリクエストの数を上書きし、50Kリクエストまで継続することを示していることに注意してください。ただし、リクエストは非常に高速に処理されたため、abは50kマークが達成されるとすぐに終了しました。この場合、22秒以内（テストにかかった時間の見出しを参照）。

*http：//127.0.0.1：8000/* を *http：//127.0.0.1：8000/admin* （web2pyアプリケーションと仮定）またはhttps:/などのサードパーティWebサイトに置き換えて同じコマンドをテストできます。/www.apache.org/では、統計の違いに注目してください。

負荷テストを実行する前のチェックリスト

テストを正常に実行し、パフォーマンスを正確に測定するのに役立ついくつかのチェックがあります。負荷テストを実行する前に、次の条件を考慮してください-

追加のPythonモジュールがロードされていないことを確認してください。
TCP/IPポートの枯渇を回避するには、通常2〜3分待ってから別のabテストに移行する必要があります。
同時接続の数がApache Worker Threadsよりも少ないことを確認してください。
Apacheまたはpythonがクラッシュした場合、別のテストを実行する前にサーバーを再起動する必要があります。

動的ページのシーケンシャルテストケース

この章では、-n *と *-c のさまざまな組み合わせと、Webサーバーの負荷を徐々に増加させる重要なフラグについて説明します。

主に、負荷を増やすと、次のメトリックがどのように変化するかに注目する必要があります-

1秒あたりのリクエスト
接続時間（ミリ秒）
特定の時間内に処理されたリクエストの割合（ミリ秒）

また、サーバーがスタックし始め、失敗した要求を取得し始めるときに、しきい値に注意する必要があります。

1人の同時ユーザーが100ページヒット

私たちは、単一のユーザーによって100の連続したページの読み込みをしましょう

$ ab -l -r -n 100 -c 1 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

出力

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:         /
Document Length:        Variable

Concurrency Level:      1
Time taken for tests:   0.045 seconds
Complete requests:      100
Failed requests:        0
Non-2xx responses:      100
Keep-Alive requests:    0
Total transferred:      27700 bytes
HTML transferred:       6600 bytes
Requests per second:    2206.24 [#/sec] (mean)
Time per request:       0.453 [ms] (mean)
Time per request:       0.453 [ms] (mean, across all concurrent requests)
Transfer rate:          596.80 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:     0    0   0.0      0       0
Waiting:        0    0   0.0      0       0
Total:          0    0   0.0      0       1

Percentage of the requests served within a certain time (ms)
  50%      0
  66%      0
  75%      0
  80%      0
  90%      1
  95%      1
  98%      1
  99%      1
 100%      1 (longest request)

それぞれ10ページのヒットを行う5人の同時ユーザー

このケースは、1か月に約50,000件以上のヒットが発生するWebサイトのピーク負荷に相当します。

$ ab -l -r -n 10 -c 5 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

次の後続の出力では、わかりやすくするために共通ヘッダーを省略します。

出力

...
Requests per second:    2009.24 [#/sec] (mean)
Time per request:       2.488 [ms] (mean)
Time per request:       0.498 [ms] (mean, across all concurrent requests)
Transfer rate:          543.52 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.5      1       2
Processing:     0    1   0.5      1       2
Waiting:        0    1   0.5      1       1
Total:          2    2   0.4      3       3
ERROR: The median and mean for the total time are more than twice the standard
       deviation apart. These results are NOT reliable.

Percentage of the requests served within a certain time (ms)
  50%      3
  66%      3
  75%      3
  80%      3
  90%      3
  95%      3
  98%      3
  99%      3
 100%      3 (longest request)

10ページのヒットをそれぞれ行う10人の同時ユーザー

このテストは、10人の異なる同時ユーザーによる100ページのロードに対応し、各ユーザーは10ページの順次ページロードを実行します。

$ ab  -r -n 10 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

出力

...
Requests per second:    2225.68 [#/sec] (mean)
Time per request:       4.493 [ms] (mean)
Time per request:       0.449 [ms] (mean, across all concurrent requests)
Transfer rate:          602.07 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   0.7      2       3
Processing:     0    2   1.0      2       3
Waiting:        0    1   1.0      2       3
Total:          4    4   0.3      4       4
WARNING: The median and mean for the waiting time are not within a normal deviation
        These results are probably not that reliable.

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      4
  80%      4
  90%      4
  95%      4
  98%      4
  99%      4
 100%      4 (longest request)

20ページのヒットをそれぞれ行う20人の同時ユーザー

このテストは、20人の異なる同時ユーザーによる400ページのロードに対応しており、各ユーザーは20ページの順次ページロードを実行しています。

$ ab -r -n 20 -c 20 -k -H “Accept-Encoding: gzip, deflate” http://127.0.0.1:8000/

出力

...
Requests per second:    1619.96 [#/sec] (mean)
Time per request:       12.346 [ms] (mean)
Time per request:       0.617 [ms] (mean, across all concurrent requests)
Transfer rate:          438.21 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    6   2.3      6      10
Processing:     1    5   2.9      5      10
Waiting:        0    5   2.9      5       9
Total:         10   11   0.6     11      12

Percentage of the requests served within a certain time (ms)
  50%     11
  66%     11
  75%     12
  80%     12
  90%     12
  95%     12
  98%     12
  99%     12
 100%     12 (longest request)

それぞれ30ページのヒットを行う30人の同時ユーザー

このテストは、30人の異なる同時ユーザーによる900ページのロードに対応し、各ユーザーは30の連続ページロードを実行します。

$ ab  -r -n 30 -c 30 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

出力

...
Requests per second:    2283.45 [#/sec] (mean)
Time per request:       13.138 [ms] (mean)
Time per request:       0.438 [ms] (mean, across all concurrent requests)
Transfer rate:          617.69 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    6   2.7      6      11
Processing:     1    6   3.1      6      11
Waiting:        0    5   3.2      5      10
Total:         11   12   0.5     12      13

Percentage of the requests served within a certain time (ms)
  50%     12
  66%     12
  75%     12
  80%     12
  90%     13
  95%     13
  98%     13
  99%     13
 100%     13 (longest request)

Webサイトの負荷を徐々に増やし、パフォーマンスをテストする方法を学びました。

Apacheベンチ-出力の比較

この章では、フラグありとフラグなしの出力を比較します。適切なフラグを使用すると、Webアプリケーションのパフォーマンスがどのように向上するかを見てみましょう。その前に、アプリケーションが単純な場合に違いに気付かない場合があることを理解する必要があります。フラグを使用する場合とフラグを使用しない場合の単純なアプリケーションの場合と同様です。次に、https://www.apache.org/URLを使用して同じテストを実行し、違いを確認します。

フラグなしでアプリケーションをテストする

このセクションでは、フラグなしでアプリケーションをテストする方法を理解します。

$ ab -n 100 -c 10 http://127.0.0.1:8000/

出力

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient).....done


Server Software:        Rocket
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:         /
Document Length:        Variable

Concurrency Level:      10
Time taken for tests:   0.244 seconds
Complete requests:      100
Failed requests:        0
Non-2xx responses:      100
Keep-Alive requests:    0
Total transferred:      27700 bytes
HTML transferred:       6600 bytes
Requests per second:    2208.77 [#/sec] (mean)
Time per request:       4.527 [ms] (mean)
Time per request:       0.453 [ms] (mean, across all concurrent requests)
Transfer rate:          597.49 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   0.7      2       3
Processing:     0    2   0.7      2       4
Waiting:        0    2   1.0      2       3
Total:          4    4   0.3      4       5

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

フラグを使用したアプリケーションのテスト

このセクションでは、フラグを使用してアプリケーションをテストする方法を理解します。

$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://127.0.0.1:8000/

出力

...
Requests per second:    2277.07 [#/sec] (mean)
Time per request:       4.392 [ms] (mean)
Time per request:       0.439 [ms] (mean, across all concurrent requests)
Transfer rate:          615.97 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    2   0.7      2       3
Processing:     0    2   0.7      2       4
Waiting:        0    2   1.0      2       3
Total:          4    4   0.2      4       5

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

出力統計に大きな違いはないことに注意してください。

フラグなしのApache組織Webサイトのテスト

フラグなしでApache Organization Webサイトをテストする方法を見てみましょう。

$ ab -n 100 -c 10 http://www.apache.org/

出力

This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking www.apache.org (be patient).....done

Server Software:        Apache/2.4.7
Server Hostname:        www.apache.org
Server Port:            80

Document Path:         /
Document Length:        58433 bytes

Concurrency Level:      10
Time taken for tests:   1.498 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      5877500 bytes
HTML transferred:       5843300 bytes
Requests per second:    66.74 [#/sec] (mean)
Time per request:       149.840 [ms] (mean)
Time per request:       14.984 [ms] (mean, across all concurrent requests)
Transfer rate:          3830.58 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       12  110 295.2     12    1012
Processing:    37   38   0.5     38      39
Waiting:       12   13   0.3     13      15
Total:         49  147 295.4     50    1051

Percentage of the requests served within a certain time (ms)
  50%     50
  66%     50
  75%     50
  80%     50
  90%    816
  95%   1050
  98%   1051
  99%   1051
 100%   1051 (longest request)

フラグを使用したApache組織Webサイトのテスト

次に、フラグを使用してApache Organization Webサイトをテストします。

$ ab -l -r -n 100 -c 10 -k -H "Accept-Encoding: gzip, deflate"  http://www.apache.org/

出力

...
Document Length:        Variable

Concurrency Level:      10
Time taken for tests:   0.357 seconds
Complete requests:      100
Failed requests:        0
Keep-Alive requests:    100
Total transferred:      1358510 bytes
HTML transferred:       1317700 bytes
Requests per second:    280.28 [#/sec] (mean)
Time per request:       35.678 [ms] (mean)
Time per request:       3.568 [ms] (mean, across all concurrent requests)
Transfer rate:          3718.41 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   3.7      0      12
Processing:    14   17  21.3     15     227
Waiting:       14   17  21.3     14     227
Total:         14   18  21.5     15     227

Percentage of the requests served within a certain time (ms)
  50%     15
  66%     15
  75%     15
  80%     15
  90%     27
  95%     28
  98%     29
  99%    227
 100%    227 (longest request)

フラグを使用すると、1秒あたりのリクエストがどのように増加したかを簡単に確認できます。この場合、特に -H "Accept-Encoding：gzip 、deflateの使用が原因です。このフラグはApacheサーバーにリクエストを gzipped 形式で処理するよう指示するためです。

Apacheベンチの結果を考慮する

Apache Benchの結果に関しては、いくつかの重要な点を考慮する必要があります。これは、アプリケーションのボトルネックを取り除き、パフォーマンスを改善するための全体的な戦略を設計するのに役立ちます。

1秒あたりのリクエスト数が必要です。これにより、Webサーバーのセットアップがどの程度うまく機能しているかがわかります。数値が大きいほど、パフォーマンスが向上します。次に、接続時間（ミリ秒）と処理された要求の割合が表示されます。これらのメトリックを目的のパフォーマンスに変更するには、Webサーバーの設定を微調整する必要がある場合があります。

Apacheまたは使用されているウェブサーバーのエラーログまたは（一般的な）ログにエラーがないか確認します。負荷を増やすと、物事が窒息し始めます。メモリの問題が発生し始めます。多くのpythonスクリプトは、並行性を念頭に置いて書かれていないとクラッシュし始めます。

Webサーバーがクラッシュしたりタイムアウトしたりする、それを超える重大な同時実行性の値を調べる必要がありますか？通常、これはかなり高い並行性レベルで発生するはずです。この値が低い場合、何かが間違っているため、これらの設定を低く/高く調整する必要があります。

結論

このチュートリアルでは、Apache Benchを使用してWebサイトまたはWebアプリケーションをロードテストする方法を学びました。 Apache Benchは、ボトルネックを減らし、パフォーマンスを向上させるために、Webアプリケーションサーバーのセットアップをどのように改善すべきかを判断するための非常に貴重なツールです。 Apache Benchの基本的な使用法を理解したので、さまざまなシナリオでアプリケーションのパフォーマンスを測定するための新しいテスト計画を作成することから始めます。

Apache-bench-quick-guide

Apacheベンチ-概要

負荷テストツールの必要性

Apache Benchとは何ですか？

Apache Benchの機能

予防措置

Apacheベンチ-環境設定

システム要件

Apache Benchのインストール

Apache Benchインストールの検証

特権Sudoユーザーの作成

Apache.org Webサイトのテスト

出力値を理解する

負荷テスト出力の迅速な分析

Apacheベンチの出力のプロット

サンプルアプリケーションのテスト

Pythonをインストールする

Bottle Frameworkのインストールと簡単なアプリケーションの作成

開発用Webサーバーを使用したアプリケーションのテスト

マルチスレッドWebサーバーを使用したアプリケーションのテスト

複数のURLを同時にテストする

単純なシェルスクリプトの作成

出力

Apacheベンチの出力をファイルに保存するシェルスクリプト

出力

警戒状況

出力

動的ページのテストの準備

同時実行レベルとリクエストの総数

フラグの使用

詳細-v

キープアライブ-k

可変ドキュメント長-l

オプション-rの使用

オプション-Hの使用

オプション-Cの使用

ApacheベンチでのセッションCookieの使用

web2pyのインストール

web2pyからのセッションCookie

出力

管理ページの確認

出力

制限時間オプションの使用

出力

負荷テストを実行する前のチェックリスト

動的ページのシーケンシャルテストケース

1人の同時ユーザーが100ページヒット

出力

それぞれ10ページのヒットを行う5人の同時ユーザー

出力

10ページのヒットをそれぞれ行う10人の同時ユーザー

出力

20ページのヒットをそれぞれ行う20人の同時ユーザー

出力

それぞれ30ページのヒットを行う30人の同時ユーザー

出力

Apacheベンチ-出力の比較

フラグなしでアプリケーションをテストする

出力

フラグを使用したアプリケーションのテスト

出力

フラグなしのApache組織Webサイトのテスト

出力

フラグを使用したApache組織Webサイトのテスト

出力

Apacheベンチの結果を考慮する

結論