この記事では、パフォーマンス テストにおけるスループットに関する核心事項について説明します。
詳細を始める前に、パフォーマンス テストの重要事項をいくつか見てみましょう。
パフォーマンス テストは次の理由から重要です。
ソフトウェア アプリケーションの開発段階のできるだけ早い段階でパフォーマンス テストを開始できます。このようにして、Web サーバーを最適化し、後の段階でのビジネスコストを防ぐことができます。
アプリケーションのデプロイメント後にパフォーマンスの問題を発見すると、問題を修正するために多くの作業時間がかかります。したがって、非常に高価になる可能性があります。
アプリケーションの基本的な Web ページが動作するとすぐに、品質保証チームは初期負荷テストを実施する必要があります。その時点から、ビルドごとに定期的にパフォーマンス テストを実行する必要があります。
アプリケーションのパフォーマンス テストにはさまざまなツールと基準があります。ここで重要な尺度であるスループットについて説明します。
すべてのソフトウェア アプリケーションや Web サイトには、さまざまなリクエストを実行する多数のユーザーがいます。テスターは、アプリケーションが稼働する前に、必要なリクエストの容量を満たしていることを確認する必要があります。
プロセス中に測定する必要があるパフォーマンス テストの基本がいくつかあります。スループットもその 1 つです。パフォーマンス テストのスループットを調べてみましょう。
テストを開始する前に、より正確で信頼性の高い結果を得ることができるように、現実的なパフォーマンス スループット目標を設定する必要があります。
現実的なスループットを決定するための重要な要素は次のとおりです。
ここでは、実際の例を使用してスループットの概念を説明します。 「ヤミー・バーガーズ」という名前のファーストフードの屋台があると想像してください。彼らは顧客にハンバーガーとフライドポテトを提供します。
「ヤミー バーガー」の屋台には 3 人の従業員がいて、各従業員が 1 人の顧客に料理を提供するのに常に 5 分かかるとします。
つまり、3 人の従業員がサービスを提供するために 3 人の顧客が並んでいる場合、「Yummy Burgers」は 5 分で 3 人の顧客に料理を提供できることになります。
したがって、「Yummy Burgers」のパフォーマンス レポートを作成する必要がある場合、そのスループットは 5 分あたり 3 人の顧客であることがわかります。
ヤミー・バーガーズのジレンマは、食べ物を待っている客の数に関係なく、特定の時間枠内に処理できる最大数は常に同じ、つまり 3 人であるということです。これが最大スループットです。
食べ物を求めて並ぶ客が増えると、順番を待たなければならず、行列ができてしまいます。
同じ概念が Web アプリケーションのテストにも当てはまります。
Web アプリケーションが 1 秒あたり 100 のリクエストを受信しても、1 秒あたり 70 のリクエストしか処理できない場合、残りの 30 のリクエストはキューで待機する必要があります。
パフォーマンス テストでは、スループットを「1 秒あたりのトランザクション数」または TPSとして表します。
Apache JMeterを使用してソフトウェア アプリケーションのパフォーマンスをテストすることは非常に一般的です。 JMeter は、アプリケーションが処理できる同時ユーザーの最大数を決定するのに役立ち、パフォーマンス テスト用のグラフィカル分析も提供します。
JMeter には、スループットの値を記録するためのさまざまな方法が用意されています。この目的に使用できるいくつかの JMeter リスナーを次に示します。
JMeter は、「 Constant Throughput Timer」というタイマー コンポーネントも提供します。これを使用して、1 秒あたりのトランザクション数 (TPS) の値を設定し、アプリケーションの負荷をテストできます。
ここで、JMeter を使用したパフォーマンス テストでのスループットの使用状況を示します。100 個の同時スレッドでサンプル テストを実行し、スループットの値を追跡するとします。
システムに JMeter の最新リリースがインストールされており、その他の必要な構成はすべてすでに実行されているとします。次に、テスト計画を作成する必要があります。
このテストでは、5 つの ThreadGroup 要素を定義します。これらの各要素には、異なるランプアップ時間 (0、15、25、35、および 45) が設定されます。ランプアップ時間は、すべてのスレッドを開始するまでの時間です。これらの ThreadGroup 要素で 100 人のユーザーを構成します。
より多くのユーザーを構成する場合は、より多くの立ち上げ時間が必要になります。
これらのスレッド グループには、サンプル Web サイト (www.samplesite.com とします) のホームページ上でリクエストを生成する HTTP サンプラーが含まれます。
使用例 1 では、100 個のスレッドで構成された ThreadGroup 要素があり、その立ち上がり時間は 0 です。
「スレッド数」フィールドは 100 に設定されます。これは、100 人のユーザーが一度にリクエストを送信することを意味します。同様に、残りの 4 つのスレッドも構成し、それらの立ち上がり時間を 15、25、35、および 45 に設定できます。また、各スレッド グループのサンプラーに名前を付けます。
前述したように、これらの HTTP サンプラーはサンプル Web サイトのホームページを指します。
これらのスレッド グループを適切な順序で実行する必要があります。このためには、コントロール パネルから [テスト計画] を選択し、[スレッド グループを連続して実行する] フィールドにチェックを入れます。
「集計レポート」は、テスト結果を分析および観察するために使用されるリスナーです。このリスナーを使用するには、「テスト計画」を右クリックして次を選択します。
追加 → リスナー → 集計レポート
次に、開始アイコンをクリックしてテストを実行します。
次に、集計レポートからスループットの結果を理解する方法を見てみましょう。
立ち上がり時間が 0 の最初のスレッド グループは、すべてのスレッドが同時に開始することによってサーバーに瞬間的な負荷をかけていることを示しています。このシナリオはスループットがかなり高くなりますが、実用的ではありません。したがって、これは現実的な出力を示しません。
2 番目と 3 番目のスレッド グループの立ち上がり時間は現実的な範囲であるため、適切なパフォーマンス スループットとリクエストの読み込み時間を示す可能性が高くなります。
スレッド グループ 4 と 5 は立ち上がり時間が長いため、スループットが低下します。
したがって、信頼できる出力は、2 番目と 3 番目のスレッド グループの結果から決定できます。
新しいリリースまたは変更を導入するかどうかは、アプリケーションが特定の TPS を処理できるかどうかに依存します。したがって、パフォーマンス テスト計画には特定のスループット目標があります。ただし、これらの目標が現実的であり、作品の真の特徴を表していることを確認する必要があります。
非現実的な条件で合格してしまったら、試験計画はすべて無駄になってしまいます。たとえば、上で説明したテスト計画では、最初のスレッド グループのスループットの値が高くなりましたが、実際の環境の実際のシナリオを示したものではありませんでした。
したがって、このような方法を使用しても、アプリケーションが実際の負荷を処理するかどうかを適切に把握することはできません。したがって、適切なテストを設定することが重要です。
一言で言えば、スループットは Web アプリケーションの重要なパフォーマンス指標です。ただし、スループット指標だけに依存するだけでは十分ではありません。したがって、遅延と応答時間をチェックする必要があります。
設定されたパフォーマンス テストの目標を達成するには、現実的なスループットを作成することも非常に重要です。