前書き
WebサイトとWebアプリケーションが機能豊富で複雑になるにつれて、パフォーマンスは開発者とユーザーの両方にとって大きな関心事になります。 studiesにより、サイトの高速化によりユーザーの関心が高まり、売り上げが増加し、トラフィックが増加することが示されているため、サイトをユーザーに迅速に配信して表示できるようにすることが重要です彼らのブラウザ。
この知識分野の一般的な用語は「Webパフォーマンスの最適化」であり、過去数年にわたって、Webエクスペリエンスを改善するための多くのベストプラクティス、技術、および技術が開発されてきました。 これらの手法の多くは、Webページのダウンロードサイズの縮小、JavaScriptの最適化、ページに必要な個々のHTTPリクエストの数の制限に焦点を当てています。
この記事では、ウェブパフォーマンスのもう一方の側面について説明します。サーバーはユーザーのリクエストにどれくらいの速度で応答できますか？ 負荷テストの一般的な状況を確認し、サーバーの実際の最大応答率を見つけるための計画を段階的に進め、オープンソースの負荷テストソフトウェアについて説明します。
用語集
始める前に、関連する用語と概念を明確にしましょう。
-
*レイテンシ*は、サーバーがクライアントからのリクエストに応答する*速度*の尺度です。 通常、ミリ秒（ms）で測定され、待ち時間は多くの場合*応答時間*と呼ばれます。 数字が小さいほど応答が速いことを示します。 レイテンシは、リクエストが送信されてからレスポンスが受信されるまで、クライアント側で測定されます。 ネットワークオーバーヘッドはこの数に含まれています。
-
*スループット*は、特定の時間間隔中にサーバーが処理できる要求の数*であり、通常は1秒あたりの要求数*として報告されます。
-
*パーセンタイル*は、サンプルセット全体のパーセンテージで結果をグループ化する方法です。 50パーセンタイルの応答時間が100ミリ秒の場合、リクエストの50％が100ミリ秒以下で返されたことを意味します。 以下のグラフは、測定値をパーセンタイルで見ることが有用な理由を示しています。 + image：https：//assets.digitalocean.com/articles/load-testing/p99.png [レイテンシ対グラフの例 99パーセンタイルで大きなスパイクを示す時間] +上のグラフは、一定期間にわたるWebサーバーの遅延を示しています。 平均（平均）応答時間はかなり一貫していますが、99パーセンタイルラインには大きなスパイクがあります。 これは、ユーザーのリクエストの1％がこの99パーセンタイルの測定よりも「さらに悪い」パフォーマンスを示しましたが、平均は比較的安定していることを意味します。 このため、パーセンタイルを見て、ユーザーが実際に経験していることをより正確に把握する価値があります。
負荷テストの基本
負荷テストは、パフォーマンスを測定し、次のようないくつかの重要な質問に答えるために、シミュレートされたHTTPトラフィックをサーバーに送信する方法です。
-
サーバーには、予想される負荷を処理するのに十分なリソース（CPU、メモリなど）がありますか？
-
サーバーは、優れたユーザーエクスペリエンスを提供するのに十分迅速に応答しますか？
-
アプリケーションは効率的に実行されていますか？
-
サーバーハードウェアを拡張する必要がありますか、それとも複数のサーバーに拡張する必要がありますか？
-
特にリソースを集中的に使用するページまたはAPI呼び出しはありますか？
負荷テストは、1台のマシン（またはマシンのクラスター）で負荷テストソフトウェアを実行して、2台目のマシン（または他のより複雑なWebサービスインフラストラクチャ）のWebサーバーへの大量のリクエストを生成することによって実行されます。 このようなツールは数多くありますが、特定のソフトウェアについては後で説明します。 ここでは、選択するソフトウェアに関係なく、関連する用語で負荷テストについて説明します。
負荷テストソフトウェアの一般的な使用法は、サーバーが処理できる* 1秒あたりの最大要求*を見つけることです。 これは、可能な限り多くのリクエストをサーバーに送信し、正常に返せるリクエストの数を確認することで行われます。
これは、サーバーの最大容量を理解するための最初のステップとして役立ちますが、ユーザーが経験するレイテンシーと実際の日々のパフォーマンスに関する多くの情報を提供しません。 負荷の高いサーバーは1秒間に1,000の応答を返すことができますが、各応答に10秒かかる場合、ユーザーは不満を感じるでしょう。
次のグラフは、スループット（1秒あたりの応答）と待機時間の関係を示しています。
image：https：//assets.digitalocean.com/articles/load-testing/latency2.png [レイテンシ対グラフの例 リクエスト、2つの間に正の相関を示す]
これは単なる例であり、すべてのセットアップに固有の応答プロファイルがありますが、一般的な傾向として、負荷が高くなる（1秒あたりの要求が増える）ことで待ち時間が長くなります。 特定の負荷でのサーバーのレイテンシをより現実的に把握するには、異なるリクエストレートで複数回テストする必要があります。 すべての負荷テストソフトウェアがこれに対応しているわけではありませんが、後でこの機能を実行できるコマンドライン負荷テストツールである「+ wrk2 +」について説明します。
負荷テストの一般的な理解が得られたので、サーバーのパフォーマンスを調査するための具体的な計画について説明します。
負荷テスト計画
サーバーとWebアプリケーションがどのようにパフォーマンスを実行し、負荷に応答しているかを把握するために実行できる一般的な手順がいくつかあります。 まず、負荷テスト中に適切なシステムリソースを監視していることを確認します。 次に、サーバーが処理できる1秒あたりの絶対最大リクエスト数を確認します。 最後に、サーバーの遅延がユーザーの許容できないパフォーマンスをもたらす最大スループットを見つけます。
ステップ1-リソースの監視
負荷テストソフトウェアは、リクエストと待機時間に関する情報を提供しますが、他のシステムメトリックを監視して、トラフィック量が多い場合にサーバーがリソースの制約を受けるかどうかを確認すると便利です。
主にCPUの負荷と空きメモリに関心があります：負荷が高い状態でこれらを見ると、インフラストラクチャを拡張する方法と、アプリケーションを開発する際にどこに労力を集中するかについて、十分な情報に基づいた決定ができます。
すでに監視システムを設定している場合（https://www.digitalocean.com/community/tutorials/how-to-use-prometheus-to-monitor-your-ubuntu-14-04-server[Prometheus ]またはhttps://www.digitalocean.com/community/tutorials/an-introduction-to-tracking-statistics-with-graphite-statsd-and-collectd[Graphite and 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
Swap: 0B 0B 0B上記の出力で強調表示されている数字は、バッファとキャッシュの使用量を差し引いた後の空きメモリを表しています。 `+ free +`の新しいバージョンは出力を変更しました：
Output total used free shared buff/cache available
Mem: 488M 182M 34M 14M 271M
Swap: 0B 0B 0B新しい「+ available +」列はわずかに異なる方法で計算されますが、一般に同じメトリック、つまりアプリケーションが使用するために現在利用可能なメモリを表します。
コマンドラインからCPU使用率を監視する場合、mpstatは、アイドル状態のCPUリソースの量の更新ビューを提供する優れたユーティリティです。 Ubuntuでは、mpstatはデフォルトではインストールされません。 次のコマンドでインストールできます：
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
08:06:28 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
08:06:30 PM all 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00「+％idle +」は、使用されていないCPUリソースの割合を示します。 CPU使用率は、多くの場合、* user * CPUや* system * CPUなどのさまざまなカテゴリに分割されるため、* use ではなく idle *を使用する理由を調べます。 これらをオンザフライで加算する代わりに、方程式のアイドル側を調べます。
サーバーのリソースを確認できるようになったので、サーバーの最大応答率を見つけるために初期負荷テストを実行しましょう。
ステップ2-最大応答率を見つける
前述のように、ほとんどの負荷テストソフトウェアは、Webサーバーの最大応答率を見つけるのに特に適しています。 多くの場合、設定する必要があるオプションは、目的の_同時実行_とテストの期間のみです。
同時実行性は、サーバーに対して行われた並列接続の数の尺度です。 これは安全なデフォルトの選択ですが、Webサーバーの「+ MaxClients 」、「 MaxThreads +」、または同様の設定をチェックして、同時接続の数を決定することで、より多くの情報に基づいた選択を行うことができます。
これらのオプションを設定することに加えて、テストに使用するURLを選択する必要があります。 ソフトウェアが一度に1つのURLしか処理できない場合、処理要件は、たとえば、ホームページと読み込みに複数のデータベースクエリを必要とする製品ページとの間で大きく異なるため、いくつかの異なるURLで複数のテストを実行する価値があります。
また、一部の負荷テストソフトウェアでは、複数のURLを指定して一度にテストできます。 これは、実際のトラフィックをより正確にシミュレートするための良い方法です。 既存のサイト使用状況データ（分析ソフトウェアまたはサーバーログから）がある場合は、テストURLと観測値を厳密に一致させることができます。
テストするURLを整理したら、負荷テストを実行します。 ソフトウェアができるだけ早くリクエストを送信していることを確認してください。 リクエストレートを選択する必要があるソフトウェアを使用している場合、大きすぎるとほぼ確実な値を選択します。 ご使用のソフトウェアに要求間の構成可能な遅延がある場合は、ゼロに減らします。
CPUとメモリのリソースが消費されていることがわかります。 サーバーがすべての要求に対応するのに苦労するため、CPUアイドルが0％に達し、負荷テストクライアントが接続エラーを受信する場合があります。 サーバーを限界まで押し進めているため、これは正常です。
すべてが終わると、ソフトウェアは* requests per second *などの統計情報を出力します。 *応答時間*にも注意してください。サーバーは極端に長くなりすぎているはずなので、非常に貧弱になる可能性があります。 このため、1秒あたりのリクエスト数は、サーバーの実際の最大スループットを示す良い指標ではありませんが、さらに調査するための良い出発点です。
次に、負荷をダイヤルしてもう一度テストし、サーバーが絶対的な制限に達していない場合のサーバーのパフォーマンスに関する詳細情報を取得します。
ステップ3-実用的な最大スループットを見つける
このステップでは、さまざまなレベルのスループットでサーバーのパフォーマンスをテストするために、少し負荷を軽減できる負荷テストソフトウェアを使用する必要があります。 一部のソフトウェアでは、各リクエスト間の遅延を指定できるようにすることでこれを実現していますが、これにより正確なスループットをターゲットにすることが難しくなります。
幸いなことに、 `+ wrk2 +`を使用すると、1秒あたりのターゲットごとに正確なリクエストを指定できます。 これを行うには、最初にいくつかのキャリブレーション要求を実行して、タイミングを適切に調整します。
前のステップの最大リクエストレートを使用して、半分に削減します。 この新しいレートで別のテストを実行し、応答時間を記録します。 まだ許容範囲内ですか？
「はい」の場合は、レートを最大値に戻し、レイテンシが許容できると判断した最大値になるまでテストしながら進みます。 これは、ユーザーがパフォーマンスの低下を経験する前にサーバーが処理できる_actual_最大応答率です。
次に、負荷テスト計画の実装に役立つオープンソースソフトウェアパッケージをいくつか見ていきます。
負荷テストソフトウェア
負荷テストに利用できる多くのオープンソースソフトウェアパッケージがあります。 さらに、負荷テストインフラストラクチャを実行し、テストデータからグラフとレポートを自動的に作成する多くの商用サービスがあります。 これらのサービスのほとんどは、大規模なインフラストラクチャをテストするために大量の負荷を生成する必要があるビジネスに適しています。ほとんどのサービスはマシンのクラスターを実行して、単一サーバーよりも多くのリクエストを生成します。
そうは言っても、一部のオープンソースツールはクラスターモードで実行することもできます。 人気のあるオープンソースツールをいくつか見て、それらの機能を要約してみましょう。
ab
ab（ApacheBenchとも呼ばれます）は、HTTPサーバーのベンチマークを行うためのシンプルなシングルスレッドのコマンドラインツールです。 最初はApache HTTPサーバーの一部として配布されていましたが、abを使用してHTTPまたはHTTPSサーバーをテストできます。
シングルスレッドであるため、abは多数のリクエストを送信するために複数のプロセッサを利用できません。 強力なWebサーバーを完全にロードしようとしている場合、これが制限になる可能性があります。
`+ ab +`コマンドの基本的な呼び出しは次のようになります。
ab -n 1000 -c 100リクエストの数（ + -n +）と同時実行性（ + -c +）を指定し、フェッチする単一のURLを指定します。 出力（以下の抜粋）には、1秒あたりの要求、要求時間、さまざまな応答時間パーセンタイルのリストが含まれています。
Output. . .
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)JMeter
JMeterは、Apache Software Foundationの強力で機能豊富な負荷テストおよび_機能テスト_アプリです。 機能テストとは、JMeterがWebサイトまたはアプリケーションが正しい出力を生成しているかどうかをテストすることもできることを意味します。
JMeterには、_Test Plans_をセットアップするためのJava GUIがあります。
image：https：//assets.digitalocean.com/articles/load-testing/jmeter.png [JMeterのデフォルトインターフェイス]
テスト計画は、JMeterのトラフィック記録Webプロキシと通常のブラウザーを使用して記録できます。 これにより、実際の使用状況をより厳密にシミュレートするトラフィックでテストできます。
JMeterは、パーセンタイル情報をHTMLレポートおよびその他の形式で出力できます。
Siege
Siegeは、abに似ていますが、いくつかの異なる機能を備えた別のコマンドライン負荷テストツールです。 Siegeはマルチスレッドであり、比較的高いスループットを可能にします。 また、負荷テストする複数のURLのリストを提供できます。 基本的な呼び出しは次のとおりです。
siege -c 100 -t 30sこれには、100の同時リクエスト（ + -c 100 +）と30秒のテスト（ + -t 30s +）が必要です。 Siegeは、平均応答時間とリクエストレートを出力します。
Output. . .
Transactions: 5810 hits
Availability: 100.00 %
Elapsed time: 29.47 secs
Data transferred: 135.13 MB
Throughput: 4.59 MB/sec
Concurrency: 2.23
. . .Siegeは、レイテンシ統計のパーセンタイル内訳を提供しません。
Locust
Locustは、結果を監視するためのリアルタイムWeb UIを備えたPythonベースの負荷テストツールです。
image：https：//assets.digitalocean.com/articles/load-testing/locust.png [イナゴのテスト結果ページ]
LocustのテストシナリオをPythonコードで記述し、すでに言語に精通している人にとって便利な強力な構成を可能にします。
Locustは分散モードで実行することもできます。このモードでは、Locustサーバーのクラスターを実行して、調整された方法で負荷を生成できます。 これにより、強力なWebサービスインフラストラクチャの負荷テストが容易になります。
Locustは、ダウンロード可能なCSVファイルで詳細な統計とパーセンタイル情報を提供できます。
wrk2
wrk2は、指定されたリクエストレートで負荷を生成できるマルチスレッドのコマンドライン負荷テストツールです。 詳細なレイテンシ統計を提供でき、Luaプログラミング言語でスクリプト化できます。
wrk2は `+ wrk `コマンドで呼び出されます（元の ` wrk +`のフォークです）：
wrk -t4 -c100 -d30s -R100 --latency上記のオプションは、4つのスレッド（ + -t4 +、マシン上のプロセッサコアの数を使用する必要があります）、100の同時要求（ + -c100 +）、30秒のテスト期間（ + -d30s +）、 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サーバーの構成を微調整して、許可する接続の数、または使用するワーカープロセスまたはスレッドの数を最適化することができます。 また、頻繁にアクセスされるデータをメモリにキャッシュして、データベースの負荷とクエリ時間を削減することもできます。
上記のトピックなどは、https：//www.digitalocean.com/community/tags/server-optimization？type = tutorials [*サーバー最適化*タグ付きチュートリアルのコレクション]にあります。