動的ページをテストするための準備

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

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

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

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

Output

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/

Output

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

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

キープアライブ-k

クライアントがHTTP要求を送信すると、サーバーに接続が確立され、サーバーが応答を送信し、要求の送信後に接続が閉じられます。このサイクルは、リクエストごとに続きます。ただし、キープアライブ設定（永続接続とも呼ばれます）を使用すると、クライアントは基盤となるTCP接続を開いたままにして、複数の要求と応答を容易にします。これにより、他の方法では存在するであろう、時間とコストのかかる接続初期化時間が排除されます。

可変ドキュメント長-l

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

オプション-rの使用

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

オプション-Hの使用

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

オプション-Cの使用

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

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

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

web2pyのインストール

別のPythonアプリweb2pyをすばやくインストールします。Web2pyフレームワークの概要でそれを使用する方法の詳細を読むことができます。

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

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

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

プロジェクトのウェブサイトから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を定義します。ただし、有効なセッションからセッション識別子cookieの値を取得する必要があります。それを取得する方法は？さまざまなオンラインチュートリアルが、Chrome（またはMozilla）ブラウザ開発ツールに向けてガイドします。ただし、テストケースでは、アプリケーションはコマンドラインでのみ使用できるため、lynxブラウザーを使用して値を取得します。

まず、セッションのCookie値を取得しましょう。別のターミナルを開き、次のコマンドを入力します-

$ lynx http://127.0.0.1:8000/

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

入力する前にCookieの値を書き留めてください yクッキーを受け入れる。これで、端末は次の画像のようになります–端末のWebサイト！

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

ここで、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は使用ロケットウェブサーバを。また、出力で前述の見出しに加えて、「非2xx応答」を取得していることにも注意してください。一般に、Httpプロトコルは応答コードを使用して要求に応答し、200秒の範囲内のすべては「大丈夫」を意味し、残りは何らかの問題に対応します。たとえば、400は、404ファイルが見つかりませんなどのリソース関連のエラーです。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オプションは注意が必要です。これを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リクエストまで継続します。ただし、リクエストは非常に高速に処理されたため、50kマークに達するとすぐに、この場合は22秒以内にabが終了しました（「テストにかかった時間」の見出しを参照）。

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

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

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

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