負荷テストの概要

序章

WebサイトとWebアプリケーションの機能が豊富で複雑になるにつれて、開発者とユーザーの両方にとってパフォーマンスが大きな懸念事項になります。の調査では、サイトの高速化によりユーザーの関心が高まり、売り上げが増加し、トラフィックが増加することが示されています。サイトをユーザーに配信してブラウザに表示するまでの時間に注意を払うことが重要です。

この分野の知識の総称はWebパフォーマンスの最適化であり、過去数年にわたって、Webエクスペリエンスを向上させるために、多くのベストプラクティス、手法、およびテクノロジが開発されてきました。これらの手法の多くは、Webページのダウンロードサイズの削減、JavaScriptの最適化、およびページに必要な個々のHTTPリクエストの数の制限に重点を置いています。

この記事では、Webパフォーマンスのもう一方の側面、つまりサーバーがユーザーの要求にどれだけ速く応答できるかについて説明します。負荷テストの一般的な状況を確認し、サーバーの最大の実用的な応答率を見つけるための計画をステップスルーし、いくつかのオープンソースの負荷テストソフトウェアについて説明します。

用語集

始める前に、いくつかの関連する用語と概念を明確にしましょう。

レイテンシーは、サーバーがクライアントからの要求に応答する速度の尺度です。通常、ミリ秒（ms）で測定され、遅延は応答時間と呼ばれることがよくあります。数値が小さいほど、応答が速いことを示します。レイテンシーは、リクエストが送信されてからレスポンスが受信されるまで、クライアント側で測定されます。ネットワークオーバーヘッドはこの数に含まれます。
スループットは、サーバーが特定の時間間隔中に処理できるリクエスト数であり、通常は1秒あたりのリクエスト数として報告されます。
パーセンタイルは、サンプルセット全体のパーセンテージで結果をグループ化する方法です。 50パーセンタイルの応答時間が100ミリ秒の場合、リクエストが100ミリ秒以内に返されるのは50% ofであることを意味します。以下のグラフは、測定値をパーセンタイルで確認することが役立つ理由を示しています。

上のグラフは、一定期間におけるWebサーバーの待機時間を示しています。平均（平均）応答時間はかなり一貫していますが、99パーセンタイルラインに大きなスパイクがあります。これは、ユーザーのリクエストの1 % oが、この99パーセンタイル測定よりもさらに悪いを実行した一方で、平均は比較的安定していることを意味します。このため、パーセンタイルを調べて、ユーザーが実際に体験していることをより正確に把握することをお勧めします。

負荷テストの基本

負荷テストは、パフォーマンスを測定し、次のようないくつかの重要な質問に答えるために、シミュレートされたHTTPトラフィックをサーバーに送信する方法です。

サーバーには、予想される負荷を処理するのに十分なリソース（CPU、メモリなど）がありますか？
サーバーは、優れたユーザーエクスペリエンスを提供するのに十分な速さで応答しますか？
アプリケーションは効率的に実行されていますか？
サーバーハードウェアをスケールアップする必要がありますか、それとも複数のサーバーにスケールアウトする必要がありますか？
特にリソースを大量に消費するページやAPI呼び出しはありますか？

負荷テストは、1台のマシン（またはマシンのクラスター）で負荷テストソフトウェアを実行して、2台目のマシン（または他のより複雑なWebサービスインフラストラクチャ）のWebサーバーに大量の要求を生成することによって実行されます。そのようなツールはたくさんありますが、後でいくつかの特定のソフトウェアを見ていきます。ここでは、選択したソフトウェアに関係なく関連する用語で負荷テストについて説明します。

負荷テストソフトウェアの一般的な使用法は、サーバーが処理できる1秒あたりの最大リクエスト数を見つけることです。これは、サーバーにできるだけ多くのリクエストを送信し、サーバーが正常に返すことができるリクエストの数を確認することによって行われます。

これは、サーバーの最大容量を理解するための最初のステップとして役立ちますが、ユーザーが経験する遅延と実際の日常のパフォーマンスに関する多くの情報は提供されません。負荷の高いサーバーは1秒あたり1,000の応答を返すことができる場合がありますが、各応答に10秒かかる場合、ユーザーは不満を抱く可能性があります。

以下のグラフは、スループット（1秒あたりの応答数）と待機時間の関係を示しています。

これは単なる例であり、すべてのセットアップに固有の応答プロファイルがありますが、一般的な傾向として、負荷が高い（1秒あたりのリクエスト数が多い）とレイテンシーが高くなります。特定の負荷でのサーバーのレイテンシーをより現実的に把握するには、さまざまなリクエストレートで複数回テストする必要があります。すべての負荷テストソフトウェアがこれに対応しているわけではありませんが、この機能を実行できるコマンドライン負荷テストツールであるwrk2については後で説明します。

妥当なレイテンシーターゲットとは何ですか？

2〜5秒の範囲のWebサイトの読み込み時間は一般的ですが、Webサーバーの遅延に起因するその時間の部分は、通常、約50〜200ミリ秒です。あなたとあなたのサイトにとって正しいことは、より具体的なターゲット数を与えるにはあまりにも多くの要因（あなたの聴衆、市場、サイトの目的、サイトのユーザー向けまたはAPIサービスなど）に依存しますが、覚えておいてくださいほとんどの研究は、速度が少しでも重要であり、「知覚できない」改善でさえ、全体として見るとより良い結果につながることを示しています。

負荷テストの一般的な理解ができたので、サーバーのパフォーマンスを調査するための具体的な計画について説明しましょう。

負荷テスト計画

サーバーとWebアプリケーションがどのように実行され、負荷に応答しているかを把握するために実行できる一般的な手順がいくつかあります。まず、負荷テスト中に適切なシステムリソースを監視していることを確認します。次に、サーバーが実行できる1秒あたりの絶対最大リクエスト数を調べます。最後に、サーバーの遅延がユーザーに許容できないパフォーマンスをもたらす最大スループットを見つけます。

ステップ1—リソースの監視

負荷テストソフトウェアは、リクエストとレイテンシに関する情報を提供しますが、他のシステムメトリックを監視して、大量のトラフィックを処理するときにサーバーがリソースに制約があるかどうかを確認すると便利です。

私たちは主にCPUの負荷と空きメモリに関心があります。負荷が高いときにこれらを監視することで、インフラストラクチャを拡張する方法や、アプリケーションを開発する際にどこに注力するかについて、より多くの情報に基づいた決定を下すことができます。

監視システム（PrometheusやGraphiteand CollectD など）を既にセットアップしている場合は、すべて設定されています。そうでない場合は、SSH経由でWebサーバーにログインし、次のコマンドラインツールを使用してリアルタイムで監視します。

使用可能なメモリを確認するには、freeコマンドを使用できます。これをwatchと組み合わせて、定期的に（デフォルトでは2秒ごとに）出力を更新します。

watch free -h

-hフラグは、freeに、バイトではなく人間が読める形式で数値を出力するように指示します。

Output             total       used       free     shared    buffers     cached
Mem:          489M       261M       228M       352K       7.5M       213M
-/+ buffers/cache:        39M       450M
Swap:           0B         0B         0B

上記の出力で強調表示されている数値は、バッファとキャッシュの使用量を差し引いた後の空きメモリを表しています。 freeの新しいバージョンでは、出力が変更されています。

Output              total        used        free      shared  buff/cache   available
Mem:           488M        182M         34M         14M        271M        260M
Swap:            0B          0B          0B

新しいavailable列の計算方法は少し異なりますが、通常は同じメトリックを表します。つまり、アプリケーションが現在使用できるメモリです。

コマンドラインからCPU使用率を監視する場合、mpstatは、アイドル状態のCPUリソースの量の更新ビューを提供する優れたユーティリティです。 mpstatはデフォルトではUbuntuにインストールされていません。次のコマンドでインストールできます。

sudo apt-get install sysstat

mpstatを起動するときは、更新の間隔を指定する必要があります。

mpstat 2

これにより、ヘッダー行が出力され、次に2秒ごとに統計の行が出力されます。

OutputLinux 4.4.0-66-generic (example-server)     08/21/2017  _x86_64_    (4 CPU)

08:06:26 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
08:06:28 PM  all    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
08:06:30 PM  all    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

%idleは、使用されていないCPUリソースの割合を示します。 使用量ではなくアイドルを確認する理由は、CPU使用率がユーザーCPUやCPUなどのさまざまなカテゴリに分割されることが多いためです。 X186X]システムCPU。これらをその場で合計する代わりに、方程式のアイドル側を調べます。

サーバーのリソースを監視できるようになったので、初期負荷テストを実行して、サーバーの最大応答率を見つけましょう。

ステップ2—最大応答率を見つける

前述のように、ほとんどの負荷テストソフトウェアは、Webサーバーの最大応答率を見つけるのに特に適しています。多くの場合、設定する必要がある唯一のオプションは、目的の同時実行性とテストの期間です。

同時実行性は、サーバーに対して行われる並列接続の数の尺度です。 100はこれに対する安全なデフォルトの選択ですが、WebサーバーのMaxClients、MaxThreads、または同様の設定をチェックして、同時に処理できる接続の数を決定することにより、より多くの情報に基づいた選択を行うことができます。

これらのオプションを設定することに加えて、テストに使用するURLを選択する必要があります。ソフトウェアが一度に1つのURLしか処理できない場合は、いくつかの異なるURLを使用して複数のテストを実行する価値があります。たとえば、ホームページと複数のデータベースクエリをロードする必要がある製品ページの間で処理要件が大きく異なる可能性があるためです。。

または、一部の負荷テストソフトウェアでは、一度にテストする複数のURLを指定できます。これは、実際のトラフィックをより正確にシミュレートするための良い方法です。（分析ソフトウェアまたはサーバーログからの）既存のサイト使用状況データがある場合は、テストURLを観測値と厳密に一致させることができます。

テストするURLを整理したら、負荷テストを実行します。ソフトウェアが可能な限り迅速にリクエストを送信していることを確認してください。リクエストレートを選択する必要があるソフトウェアを使用している場合は、大きすぎることがほぼ確実な値を選択してください。ソフトウェアにリクエスト間に設定可能な遅延がある場合は、それをゼロに減らします。

CPUとメモリのリソースが消費されていることを確認する必要があります。サーバーがすべての要求に対応するのに苦労しているため、CPUアイドル状態が0％に達し、負荷テストクライアントが接続エラーを受け取る可能性があります。サーバーを限界まで押し上げているため、これは正常です。

それがすべて終わると、ソフトウェアは1秒あたりのリクエスト数を含むいくつかの統計を出力します。 応答時間にも注意してください。サーバーが極端に拡張されているはずなので、非常に貧弱である可能性があります。このため、1秒あたりのリクエスト数は、サーバーの実際の最大スループットを示す良い指標ではありませんが、さらに調査するための良い出発点です。

次に、負荷をダイヤルバックして再度テストし、サーバーが絶対制限に達していない場合のサーバーのパフォーマンスに関する詳細情報を取得します。

ステップ3—最大の実用的なスループットを見つける

このステップでは、負荷を少し下げることができる負荷テストソフトウェアを使用して、さまざまなレベルのスループットでサーバーのパフォーマンスをテストする必要があります。一部のソフトウェアは、各要求間の遅延を指定できるようにすることでこれを行いますが、これにより、正確なスループットをターゲットにすることが困難になります。

幸い、wrk2を使用すると、1秒あたりの正確なリクエスト数を指定できます。これを行うには、最初にいくつかのキャリブレーションリクエストを実行して、タイミングを適切に調整します。

前のステップからの最大要求率を取り、それを半分に減らします。この新しいレートで別のテストを実行し、応答時間を記録します。それはまだ許容範囲内ですか？

はいの場合は、レートを最大値に戻し、レイテンシーが許容できると判断した最大値になるまでテストします。これは、ユーザーがパフォーマンスの低下を経験する前にサーバーが処理できる実際の最大応答率です。

注：用語集で説明したように、レイテンシを測定するときは、99パーセンタイルまたは99.999パーセンタイルのようなものを調べて、すべてのユーザーが定期的に応答を経験していることを確認する必要があります最大許容しきい値を下回っている時間。ほとんどのWebページでは、すべてのアセット（画像、JavaScript、CSSファイルなどを含む）をフェッチしてページをレンダリングするために、数十のリクエストが必要であることに注意してください。 Webページの完了に10のリクエストが必要で、99パーセンタイルを測定している場合、ページの読み込みの約10 % o fでも、より高いレイテンシで1つのリクエストが発生します。

次に、負荷テスト計画の実装に役立ついくつかのオープンソースソフトウェアパッケージを見ていきます。

負荷テストソフトウェア

負荷テストに利用できる多くのオープンソースソフトウェアパッケージがあります。さらに、負荷テストインフラストラクチャを実行し、テストデータからグラフとレポートを自動的に作成する多くの商用サービスがあります。これらのサービスは、大規模なインフラストラクチャをテストするために大量の負荷を生成する必要がある企業に適しています。これらのサービスのほとんどは、マシンのクラスターを実行して、単一のサーバーよりも多くの要求を生成するためです。

とはいえ、一部のオープンソースツールはクラスターモードで実行することもできます。より人気のあるオープンソースツールのいくつかを見ていき、それらの機能を要約してみましょう。

ab

ab（ApacheBenchとも呼ばれます）は、HTTPサーバーのベンチマークを行うためのシンプルなシングルスレッドのコマンドラインツールです。元々はApacheHTTPサーバーの一部として配布されていましたが、abを使用して任意のHTTPまたはHTTPSサーバーをテストできます。

シングルスレッドであるため、abは複数のプロセッサを利用して大量のリクエストを送信することはできません。強力なWebサーバーを完全にロードしようとしている場合、これは制限になる可能性があります。

abコマンドの基本的な呼び出しは次のようになります。

ab -n 1000 -c 100 http://example.com/

リクエストの数（-n）と同時実行性（-c）を指定してから、フェッチする単一のURLを指定します。出力（以下に抜粋）には、1秒あたりのリクエスト数、リクエスト時間、およびさまざまな応答時間のパーセンタイルのリストが含まれています。

Output. . .
Requests per second:    734.76 [#/sec] (mean)
Time per request:       136.098 [ms] (mean)
Time per request:       1.361 [ms] (mean, across all concurrent requests)
Transfer rate:          60645.11 [Kbytes/sec] received

Percentage of the requests served within a certain time (ms)
  50%    133
  66%    135
  75%    137
  80%    139
  90%    145
  95%    149
  98%    150
  99%    151
 100%    189 (longest request)

JMeter

JMeterは、ApacheSoftwareFoundationの強力で機能豊富な負荷テストおよび機能テストアプリです。機能テストとは、JMeterがテストして、Webサイトまたはアプリケーションが正しい出力を生成していることを確認できることを意味します。

JMeterには、テストプランを設定するためのJavaGUIがあります。

テストプランは、JMeterのトラフィック記録Webプロキシと通常のブラウザを使用して記録できます。これにより、実際の使用をより厳密にシミュレートするトラフィックでテストできます。

JMeterは、パーセンタイル情報をHTMLレポートやその他の形式で出力できます。

包囲

Siegeは、abに似ていますが、いくつかの異なる機能を備えた、もう1つのコマンドライン負荷テストツールです。 Siegeはマルチスレッドであり、比較的高いスループットを可能にします。また、負荷テストを行う複数のURLのリストを提供することもできます。基本的な呼び出しは次のとおりです。

siege -c 100 -t 30s http://example.com/

これには、100の同時リクエスト（-c 100）と30秒のテスト（-t 30s）が必要です。 Siegeは、平均応答時間と要求率を出力します。

Output. . .
Transactions:               5810 hits
Availability:             100.00 %
Elapsed time:              29.47 secs
Data transferred:         135.13 MB
Response time:               0.01 secs
Transaction rate:      197.15 trans/sec
Throughput:             4.59 MB/sec
Concurrency:                2.23
. . .

Siegeは、レイテンシ統計のパーセンタイル内訳を提供しません。

イナゴ

Locustは、結果を監視するためのリアルタイムWebUIを備えたPythonベースの負荷テストツールです。

LocustテストシナリオをPythonコードで記述し、言語に既に精通している人にとって便利な強力な構成を可能にします。

Locustは分散モードで実行することもできます。このモードでは、Locustサーバーのクラスターを実行し、それらに調整された方法で負荷を生成させることができます。これにより、強力なWebサービスインフラストラクチャの負荷テストが容易になります。

Locustは、ダウンロード可能なCSVファイルで詳細な統計とパーセンタイル情報を提供できます。

wrk2

wrk2は、指定された要求レートで負荷を生成できるマルチスレッドのコマンドライン負荷テストツールです。詳細なレイテンシ統計を提供でき、Luaプログラミング言語でスクリプト化できます。

wrk2は、wrkコマンドで呼び出されます（元のwrkのフォークです）。

wrk -t4 -c100 -d30s -R100 --latency http://example.com/

上記のオプションは、4つのスレッド（-t4、マシン上のプロセッサコアの数を使用する必要があります）、100の同時リクエスト（-c100）、30秒のテスト期間（ [X184X ]）、および1秒あたり100リクエストのリクエストレート（-R100）。最後に、--latencyを使用して詳細なレイテンシ出力を要求します。

Output. . .
Latency Distribution (HdrHistogram - Recorded Latency)
50.000%    5.79ms
75.000%    7.58ms
90.000%   10.19ms
99.000%   29.30ms
99.900%   30.69ms
99.990%   31.36ms
99.999%   31.36ms
100.000%   31.36ms
. . .

上記の出力は抜粋です。より詳細なレイテンシパーセンタイルも出力されます。

結論

この記事では、負荷テストの用語と基本概念を確認し、1秒あたりの最大の実用的なリクエストを見つけるための計画をたどり、ハードウェアと開発の取り組みに関する将来の決定を導くためのシステムリソースを観察し、利用可能なオープンソースのいくつかを調べました。負荷テストソフトウェア。

インフラストラクチャのパフォーマンスを測定した後、この情報に基づいて応答時間を改善し、サーバーの負荷を軽減することをお勧めします。 Webサーバーのハードウェアをスケールアップするか、複数のサーバーとロードバランサーを使用してスケールアウトすることをお勧めします。 Webサーバーの構成を微調整して、許可する接続の数や、使用するワーカープロセスまたはスレッドの数を最適化することができます。また、頻繁にアクセスされるデータをメモリにキャッシュして、データベースの負荷とクエリ時間を削減することもできます。

上記のトピックなどは、サーバー最適化タグ付きチュートリアルのコレクションにあります。