JMeterパフォーマンステスト—ワークロードモデルにおけるリトルの法則の適用
Jmeter Performance Test Application Littles Law Workload Model
リトルの法則は、最も有名な待ち行列理論の1つである必要があります。パフォーマンステストに使用する方法を見てみましょう。
リトルの法則
安定したシステムの長期平均顧客数（N）は、長期平均実効到着率（λ）にシステムの顧客が費やした平均時間（W）を掛けたものに等しく、代数として表すことができます。式：N =λW。
リトルの法則は普遍的に適用可能であり、小売店からCPU /アプリケーションサーバーまで、キューがある場所ならどこでも適用できます。
チケットカウンターのユーザーが平均15分（W）を費やし、顧客が1時間あたり20人の顧客（λ）の割合で到着し、全員がチケットを購入すると仮定します。
リトルの法則を使用すると、いつでもシステム内の平均顧客数をN =λWとして計算できます。
λ = 20 /時間
に = 15分= 0.25時間
したがって、 N 5 =（0.25 * 20）
1時間あたり20人の顧客を期待できますが、顧客はカウンターで15分しか費やさないため、システムには5人の顧客しかなく、4人がキューにいて、1人がメンテナンス中です。
到着率：
顧客がシステムに入るレートは、到着レートと呼ばれます。
離脱率：
顧客がシステムを離れる速度は、離脱率と呼ばれます。
リトルの法則は、システムが安定していることを前提としているため、到着率と出発率は同じです。
パフォーマンステストにおけるリトルの法則：
リトルの法則をWeb / APP /データベースサーバーに適用して、ユーザー/リクエストの総数、サーバースループット（TP）、および平均応答時間を相関させることもできます。
スループット ------は、終了率（λ）として使用できる単位時間あたりに処理された要求の数です。
反応時間 ------平均応答時間は、システムでの要求に費やされた時間（W）です。待ち時間+サービス時間が含まれます。
N =スループット*応答時間（N =スループット*応答時間）
思考時間はシステムスループットに影響します。したがって、考える時間があれば：
N =スループット*（応答時間+思考時間）
パフォーマンステスト結果の検証：
リトルの法則を使用してパフォーマンステストの実行結果を検証できる理由を理解するために、いくつかの例を見てみましょう。
私たちのTomcatサーバーでは、server.xmlのスレッドプール内のスレッドの最大数を更新すると、10の同時実行しか処理できません。 10を超えると、並んで待機します。ここでリトルの法則を適用する方法を見てみましょう。
また、応答時間を制御し、tomcatの例のhello.jspファイルを更新し、2000ミリ秒待機するディスプレイを追加します。tomcatはこの要求を処理して応答するのに2秒かかります。
これで、ページへの各リクエストの処理に2秒かかることがわかりました。また、プールには10個のスレッドしかないこともわかりました。
したがって、tomcatは2秒以内に10個のリクエストを処理でき、tomcatのサーバースループットを（10/2 =）に制限します。 5リクエスト/秒 。
10人の同時ユーザーがページにアクセスする簡単なテストを作成し、一定期間テストしました。
JMeterの上記の要約結果によると：
平均応答時間（W）は 2009ミリ秒
スループット（λ）は 5秒
したがって、システム内のユーザー数 N1N = Throughput* Response time 2N = 5 * 2.009 3N = 10.045, very close to 10今回は、50人の同時ユーザーに対して同じテストを実行し、次の結果が得られました。
1W = 9.742 seconds 2λ = 5/sec 3N = 9.742* 5 = 48.71, close to 50これにより、応答時間がユーザーの負荷と同期していることが確認されます。上に示したように、リトルの法則を使用して、パフォーマンステスト結果の精度を検証できます。
ワークロードモード：
ワークロードパターンは テスト対象のシステムの動作を分析するために使用される、特定の同時ユーザーによって特定の時間に実行される一連のビジネストランザクション。
ワークロードモードは、パフォーマンステストで非常に重要です。エンドユーザーのモードが反映されていない場合、パフォーマンステストの結果は無駄になります。
ユーザー数をランダムに考慮し、任意の思考時間を持った単純なパフォーマンステスト計画を作成することはできません。
適切なワークロードパターンを見つけるには、少なくとも次の情報を提供する必要があります。
主要な商取引
Vユーザーの数
稼働中のユーザーの割合
考える時間
期待されるスループット
通常、上記の情報は顧客/ビジネスアナリストなどによって提供される必要がありますが、パフォーマンステストエンジニアとして、問題が発生する場合があります。つまり、顧客は非機能要件について何も知りません。ただし、パフォーマンステストを実行したいので、Googleアナリティクスツールを使用してリトルの法則を使用してワークロードパターンに到達する方法を見てみましょう。
Google Analyticsは、頻繁にアクセスするページを提供できます。これは、これらのページや特定の操作に関与するユーザーの割合を扱うビジネスワークフローに役立つ情報です。
スループットの計算：
アプリケーションの1つについて、google-analyticsは1年の特定の日にピーク情報を表示します。
20071ユーザーがログインしました
277576ページビュー
ページビューから、サーバーのスループットを計算できます。
つまり、サーバーが1日あたり277,576ページを処理する場合、1秒あたり3.2ページの要求を処理します。 （277576 /（24 * 60 * 60））
しかし、これは正しくありません！
Google Analyticsは、その日のページビューの分布も提供します。ピーク時には、サーバーは1時間で34,435ページを処理しました。
したがって、このピーク時間を目的のスループット計算に使用できます。 34435 /（60 * 60）は9.56ページ/秒を提供します。これは、予想されるスループットであるはずです。
思考時間の計算：
上の図からわかるように、ユーザーセッションは9分15秒、つまり555秒続きました。
セッション中、ユーザーは8.78ページを閲覧しました。
2つのページビュー間の時間間隔は555 / 8.78 = 63秒です
応答時間+思考時間= 63秒
応答時間がわかっていれば、それに応じて思考時間を調整できます。
ユーザー計算の総数：
Google Analyticsは、ピーク時に約3904人のユーザーがいることも示しています。
実際、これは、3904人の同時ユーザーで負荷テストを実行する必要があるという意味ではありません。 1時間の集計情報だからです。
リトルの法則によると、 ユーザーの総数N =スループット*（応答時間+思考時間）
1 N = 9.56 * 63 2 N = 602 users 負荷テストを実行するには、602人の同時ユーザーで十分です。
つまり、9分15秒と602ユーザーのテスト計画を設計することで、3910ユーザーがログインすることになります。これは、現在の本番ワークロードに非常に近いものです。
総括する：
一部のパフォーマンステスターは、JMeter / LoadRunnerまたはその他のツールを使用してテスト計画を作成する方法を知っている場合があり、どのような結果が得られても正確であると信じています。しかし、物事は裏目に出ました！
例：システムリソースが非常に限られている場合があります。1,000人の同時ユーザーに対してJMeterテストを実行すると、JMeterは結果が正しいとは決して想定せず、常にリトルの法則を使用して結果をクロスチェックする結果を返します。 JMeterの結果によると、スループットが50 /秒で、平均応答時間（思考時間を含む）が13秒であると仮定します。
1 N = 50 * 13 2 3 N = 650 4 5 Our expectation N should be around 1,000. So there is a problem here! ! したがって、リトルの法則を使用して、観測されたパフォーマンス結果が、負荷生成ツールによって引き起こされたボトルネックによるものではないことを確認できます。
エラーがある場合は、それを指摘してください、メッセージを残すことを歓迎します
以前の素晴らしい記事：
Jmeterパラメーター化の複数の方法
パフォーマンステスト自動化フレームワーク-Jenkins + Ant + Jmeter