序章

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

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

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

用語集

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

  • レイテンシーは、サーバーがクライアントからの要求に応答する速度の尺度です。 通常、ミリ秒（ms）で測定され、遅延は応答時間と呼ばれることがよくあります。 数値が小さいほど、応答が速いことを示します。 レイテンシーは、リクエストが送信されてからレスポンスが受信されるまで、クライアント側で測定されます。 ネットワークオーバーヘッドはこの数に含まれます。

  • スループットは、サーバーが特定の時間間隔中に処理できるリクエスト数であり、通常は1秒あたりのリクエスト数として報告されます。

  • パーセンタイルは、サンプルセット全体のパーセンテージで結果をグループ化する方法です。 50パーセンタイルの応答時間が100ミリ秒の場合、リクエストが100ミリ秒以内に返されるのは50% ofであることを意味します。 以下のグラフは、測定値をパーセンタイルで確認することが役立つ理由を示しています。

    An example graph of latency vs. time, showing a large spike in the 99th percentile

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

負荷テストの基本

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

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

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

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

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

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

An example graph of latency vs. requests, showing a positive correlation between the two

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

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

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

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

負荷テスト計画

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

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

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

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

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

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

  1. 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にインストールされていません。 次のコマンドでインストールできます。

  1. sudo apt-get install sysstat

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

  1. mpstat 2

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

Output
Linux 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使用率がユーザー