ストレステストツールの一つであるabの基本的な使い方について解説します。
abのインストール
macOSではデフォルトでインストール済みのため、すぐに使用できます。
Ubuntuの場合は、以下のコマンドでインストールできます。
sudo apt install apache2-utils基本的な使い方
最も重要な-nオプションと-cオプションについて説明します。
ab -n [全リクエスト数] -c [同時接続数] [URL]-n：総リクエスト数を指定します-c：同時に送信するリクエスト数（同時接続数）を指定します[URL]：テスト対象のURL
-nで指定したリクエスト数を-cで指定した多重度で送信します。-cで指定した多重度でそれぞれが-nで指定したリクエスト数を送信するのではない点に注意してください。
例えば、総リクエスト数1,000（-n 1000）を4多重（-c 4）で実行した場合、実際に送信されるリクエストは4,000ではなく1,000になります。ただし、総リクエスト数は多重度で割り切れる必要はなく、総リクエスト数1,000に対して3多重という設定も可能です。
実行例
例えば、http://localhost:8080に対して、計1,000回のリクエストを10多重で送信する場合は以下のようにします。
$ ab -n 1000 -c 10 http://localhost:8080/
This is ApacheBench, Version 2.3 <$Revision: 1903618 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: Apache/2.4.56
Server Hostname: localhost
Server Port: 8080
Document Path: /
Document Length: 49730 bytes
Concurrency Level: 10
Time taken for tests: 4.907 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 50006000 bytes
HTML transferred: 49730000 bytes
Requests per second: 203.77 [#/sec] (mean)
Time per request: 49.075 [ms] (mean)
Time per request: 4.907 [ms] (mean, across all concurrent requests)
Transfer rate: 9950.92 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.2 0 5
Processing: 35 48 12.5 46 266
Waiting: 34 45 7.8 44 88
Total: 36 48 12.5 46 266
Percentage of the requests served within a certain time (ms)
50% 46
66% 49
75% 52
80% 54
90% 59
95% 65
98% 73
99% 76
100% 266 (longest request)実行結果の見方
先ほど示した実行例をもとに実行結果のうち、主な項目についての見方を説明します。
Requests per secondは、1秒あたりのリクエスト数をあらわしています。実行例では203.77となっており、1秒あたり203リクエストを処理していることがわかります。
Time per requestは、1リクエストあたりの平均応答時間をあらします。実行例では2つのTime per requestがあり、最初のTime per requestは1リクエストあたりの平均応答時間で、平均49.075msで処理できていることがわかります。もう一つのTime per requestは、多重度を考慮した平均応答時間で、今回は10多重にしているため、1/10にあたる4.907msで1リクエストが処理できていることをあらわしています。
Transfer rateは、平均転送速度で、1秒あたりに転送されるデータ量をあらわします。実行例では、9950.92Kbytes/secで転送しており、1秒あたり10MB近い転送速度になっています。
Complete requestsは完了したリクエスト数をあらわし、Failed requestsは正常に処理できなかったリクエスト数をあらわします。実行例では、1,000リクエスト中、正常に処理できなかったリクエストは0になっています。負荷を上げていくとFailed requestsが0でなくなるタイミングがでてきます。これが性能限界をあらわしています。
例えば、実行例と同じ環境で20,000リクエストを200多重で行った結果は以下のようになりました。2リクエストはレスポンスの長さが想定と異なるエラーが発生しています。
Complete requests: 20000
Failed requests: 2
(Connect: 0, Receive: 0, Length: 2, Exceptions: 0)括弧内のエラーの意味は以下のようになります。
- Connect: サーバへの接続の際のエラー数。ネットワークの問題やサーバの過負荷、サーバのダウンなどが原因で接続できなかった場合にこの数が増えます
- Receive: サーバからのレスポンスの受信中に発生したエラー数。サーバからの応答が途中で切断されるなどの理由でこの数が増えることがあります
- Length: レスポンスの内容の長さが予期したものと異なる場合のエラー数。たとえば、予期していたHTMLページのサイズと実際に受信したサイズが異なる場合にこのエラーがカウントされます
- Exceptions:
ab自体がエラーを捕捉した場合の数。これは通常、予期しないエラーや問題がabの実行中に発生した場合にカウントされます
Length
今回使用しているURLは固定のページを返しているため、リクエストの度にレスポンスの長さが変わることはありません。このことから、2回のLengthはエラーであるといえます。しかし、このエラー判定は同じURLが返すレスポンスの長さは常に同じという前提のもとに判定されているため、Webアプリケーションによってはリクエストごとにレスポンスの長さが変わる場合もありますので、必ずしもエラーとなりません。また、このLengthはHTTPヘッダーのContent Lengthと一致していないという判定でもない点に注意が必要です。
404エラー、500エラー
もう一つ重要な点が404エラーや500エラーを検知しない点です。負荷を上げたときにサーバーで500エラー担った場合でもレスポンスが返せているのであれば、ExceptionsやReceiveではなく、Lengthとして検知されます。
そのため、設定が誤っていて404エラーになるURLを指定してしまった場合でもエラーにはならずすべて正常に処理されます。
エラーの発生状況や正しいURLを実行できていることはアクセスログなどのサーバーログを併用して確認することが重要です。
その他の主要オプション
その他の主要オプションとして、-Aオプション、-Cオプション、-Hオプションを紹介します。
BASIC認証情報を設定する-Aオプション
BASIC認証でアクセス制限を行っている場合、-Aオプションを使って認証情報を設定します。
-A <ユーザーID>:<パスワード>の形式で認証を情報を設定します。例えば、ユーザーID「user」、パスワード「password」で認証できるBASIC認証が設定されているサイトの場合、
$ ab -n 1000 -c 10 -A user:password http://localhost:8080/のように指定します。
Cookieを設定する-Cオプション
認証情報をCookieで設定する場合などは-Cオプションを使用してCookieを設定します。
-C "<Cookie名>=<値>"の形式で設定し、複数ある場合は-Cオプションを複数設定します。例えば、JWTトークン12345をtokenというCookie名で送信する場合、
$ ab -n 1000 -c -C "token=12345" http://localhost:8080/のように指定します。
HTTPヘッダーを設定する-Hオプション
HTTPヘッダーを設定する場合は、-Hオプションを使用します。
-H "<ヘッダー名>: <値>"の形式で設定し、複数ある場合は-Hオプションを複数設定します。例えば、Accept-EncodingヘッダーとAccept-Languageヘッダーを設定する場合は、
$ ab -n 1000 -c 10 -H "Accept-Encoding: gzip, deflate, br" -H "Accept-Language: en-US,en;q=0.9,ja;q=0.8" http://localhost:8080/のように指定します。
実行結果をファイルに出力する
実行結果をファイルに出力するオプションがいくつか用意されています。
HTML形式で出力する
テキスト形式で表示していた実行結果をHTML形式で出力するには-wオプションを使用します。このオプションを使用することでこれまでテキスト形式で出力されていた内容をHTML形式で出力できるようになります。コンソールにそのまま表示してもわかりにくいだけですので、基本的にはリダイレクトでファイルに出力して使用します。
$ ab -n 1000 -c 10 -w http://localhost:8080/ > result.html最低限のタグ付けがされているだけですので、見た目はそれほどきれいという訳ではありません。
CSV形式で出力する
-eオプションで出力先のファイル名を指定することで、テキスト形式で表示していた内容とは別に0%から100%までのパーセンタイル情報がCSV形式で出力されます。
$ ab -n 1000 -c 10 -e result.csv http://localhost:8080/
$ head result.csv
Percentage served,Time in ms
0,34.739
1,36.607
2,37.105
3,37.471
4,37.737
5,38.012
6,38.288
7,38.449
8,38.511 0の行が最速のレスポンス時間、50の行が中央値のレスポンス時間、100の行が最遅のレスポンス時間ををあらわします。
実行結果に表示されているPercentage of the requests served within a certain time (ms)のうち、50%が50の行、100%が100の行に対応しています。
TSV形式で出力する
最も使用することが多いのが-gオプションです。TSV形式としていますが、正確にはgnuplotフォーマットになりますが、実質的にTSVファイルとして扱って問題がありません。
$ ab -n 1000 -c 10 -g result.tsv http://localhost:8080/
$ head result.tsv
starttime seconds ctime dtime ttime wait
Sun Oct 29 00:05:31 2023 1698505531 0 36 36 35
Sun Oct 29 00:05:29 2023 1698505529 0 36 37 36
Sun Oct 29 00:05:30 2023 1698505530 0 37 37 35
Sun Oct 29 00:05:29 2023 1698505529 0 37 37 36
Sun Oct 29 00:05:29 2023 1698505529 0 37 37 35
Sun Oct 29 00:05:30 2023 1698505530 0 36 37 35
Sun Oct 29 00:05:29 2023 1698505529 0 37 37 36
Sun Oct 29 00:05:29 2023 1698505529 0 37 37 36
Sun Oct 29 00:05:30 2023 1698505530 0 37 37 36各カラムの意味は以下の通りです。
- starttime: リクエストが開始された時刻。通常はエポックタイム（1970年1月1日からの経過秒数）で表される
- seconds: リクエスト開始時間をエポックタイム（秒）
- ctime: 接続時間。ターゲットサーバーへの接続が確立されるまでの時間（ミリ秒）
- dtime: 処理時間。リクエストが送信されてからレスポンスが完全に受信されるまでの時間（ミリ秒）
- ttime: 合計時間。接続の確立からレスポンスの完全な受信までの合計時間（ミリ秒）
- wait: 応答待機時間。リクエストが完全に送信されてから最初のレスポンスバイトが受信されるまでの時間（ミリ秒）
この形式での出力ではいろいろな情報が得られます。
例えば、ctimeが長すぎる場合はサーバーが待ち受けられる接続の上限に達している可能性がありますし、waitが長すぎる場合はサーバーの処理に遅延が発生していたり、ワーカースレッドが足りない可能性があります。リクエストがエラーになっている原因やパフォーマンスが低下している原因を推測するための一助となる情報が得られる点では重要です。
abではできないこと
abはストレステストツールとして優秀ですが、シナリオテストような一連のURLを順番にアクセスするといった使い方はできません。シナリオテストで負荷をかける場合は、JMeterなどを使用してください。
まとめ
abはランディングページなど静的なサイトでのストレステストでは積極的に採用できます。ただし、クライアントで状態を管理していたり、特定の手順で負荷をかけたい場合はJMeterなど他のツールを採用する必要があります。
すばやく導入でき、複雑な設定なしで使用可能なため、サクッと負荷をかけたい場合は是非abを使ってみてください。