Webアプリケーションのスレッドプールサイズの決定方法


Webアプリケーションのスレッドプールサイズの決定方法


ラベル(スペース区切り):Thread Pool Web
本文の原文はHow To Determine WebアプリケーションThread Pool Size
引き続き、Webアプリケーションを拡張する際に直面するアーキテクチャの問題について説明します.このブログでは、Webアプリケーションのスレッドプールのサイズをどのように決定するかについてよくある問題を紹介します.Webアプリケーションを本番に導入するか、Webアプリケーションのパフォーマンステストを行うと表示されます.

スレッドプール


Webアプリケーションでは、スレッドプールのサイズによって、いつでも処理できる同時リクエストの数が決まります.Webアプリケーションがスレッドプールよりも多くのリクエストを取得した場合、余分なリクエストはキューに並ぶか拒否されます.
同時は並列ではないことに注意してください.コンカレント要求は、任意の時点で少数の要求のみがCPU上で処理されている要求の数である.パラレル要求は、任意の時点ですべての要求がCPU上で実行できる処理中の要求数である.
NodeJSなどの非ブロックI/Oアプリケーションでは、1つの単一プロセス(スレッド)で複数の要求を同時に処理できます.マルチコアCPU環境では、プロセスまたはスレッド数を増やすことでパラレル要求を処理できます.
ブロックI/Oアプリケーションでは、Java SpringMVCのように、単一プロセスで1つのリクエストを同時に処理することができます.より多くのリクエストを同時に処理するために、スレッド数を増やさなければなりません.

CPU制限のアプリケーション


CPUが制限するアプリケーションは、スレッドプールのサイズがシステム内のCPUの数に等しいはずです.より多くのスレッドを追加すると、スレッドコンテキストが切り替わるため、リクエスト処理が中断され、応答時間も増加します.
I/Oブロックされていないアプリケーションは、要求が処理されると、スレッド待ち時間がないため、CPUによって制限されます.

I/O制限アプリケーション


I/O制限アプリケーションのスレッドプールのサイズを決定するのは複雑で、1つのスレッドが他のシステムが応答するまでブロックされるため、下流システムの応答時間に依存します.Reactor Pattern Part 1:Applications with Blocking I/Oで議論されているように、CPUをよりよく利用するためにスレッドの数を増やさなければなりません.

リトルの法則


リトル法則は、銀行が銀行に入った顧客を処理するために必要な出納台の数を計算する必要があるなど、非技術分野に用いられる.
Little’s law
The long-term average number of customers in a stable system L is equal to the long-term 
average effective arrival rate, λ, multiplied by the average time a customer spends 
in the system, W; or expressed algebraically: 
L = λW.

リトルの法則はWebアプリケーションに適用される.
  web  (  web  ), (ResponseTime)。

スレッド=スレッド数毎秒webリクエスト数=1 sで処理可能なwebリクエスト数応答時間=1つのwebリクエストを処理するのにかかる時間
  = (  web  ) X  

以上の式が、入力された要求を処理するために必要なスレッド数を提供する場合、スレッドCPU利用率の情報は提供されない.例えば、所与のシステムのX CPUにどのスレッドが割り当てられるべきか.

テストスレッドプールサイズの決定


スループットと応答時間の最適なバランスを見つけるためのスレッドプールサイズ.各CPU最小スレッド起動開始(Threads Pool Size=No of CPU)は、CPU使用率が爆発したり、応答時間が劣化したりするまで、アプリケーションスレッドプールのサイズが下流システムの平均応答時間に直接比例する.
次の図では、要求数、CPU、接続応答時間の指標をいくつ説明します.
CPU Vsリクエスト数グラフは、Webアプリケーションの負荷が増加した場合のCPUの利用率を示している.
応答時間Vs要求数グラフは、Webアプリケーションの負荷が増大することによる応答時間への影響を示す.
緑の点は、最適なスループットと応答時間を表します.
スレッドプールサイズ=CPU数
以上のグラフでは、スレッド数がCPU数に等しい場合に、ブロックI/O制限アプリケーションについて説明しています.アプリケーション・スレッドがブロックされ、下流システムの応答を待機します.スレッドがブロックされるため、リクエストがキューに入るにつれて応答時間が増加します.CPUの使用率が非常に低くても、すべてのリクエストがブロックされるにつれて、アプリケーションはリクエストを拒否し始めます.
大スレッドプール
以上のグラフでは、Webアプリケーションで多数のスレッドが作成されると、ブロックI/Oがアプリケーションを制限することを示しています.大量のスレッドのため、スレッドの切り替えは非常に頻繁になります.スループットが増加しなくても、不要なスレッドコンテキスト切り替えのため、アプリケーションのCPU使用率が満たされます.コンテキスト切替によるリクエストが中断されたため、応答時間がダウングレードされる.
最適スレッドプールサイズ
上記のグラフでは、Webアプリケーションで最適スレッドプールサイズが作成された場合に、ブロックI/Oがアプリケーションを制限することを示しています.CPUは有効に使用され、良好なスループットとより少ないスレッドコンテキストによって切り替えられる.応答時間は,要求による効率的な処理(少ない割り込み)に適していることに気づいた.

スレッドプールの分離


ほとんどのWebアプリケーションでは、一部のタイプのWebリクエストは、他のタイプのWebリクエストに比べて処理に時間がかかります.最も遅いリクエストは、すべてのリクエストを特定し、アプリケーション全体のパフォーマンスを低下させます.
2つの方法でこの問題を処理します.
  • は、遅いWeb要求
  • を処理するための個別のシステムを有する.
  • 同じアプリケーションにおいて遅いウェブ要求に割り当てられた個別のスレッドプール
  • I/O Webアプリケーションをブロックする最適なスレッドプールサイズを決定することは、非常に困難なタスクです.通常、いくつかのパフォーマンスの実行によって完了します.いくつかのスレッドプールは、Webアプリケーションで最適なスレッドプールサイズを決定するプロセスをより複雑化します.