Hitachi

VisiBroker Version 5 Borland(R) Enterprise Server VisiBroker(R) デベロッパーズガイド


8.3 スレッドプーリングポリシー

サーバがスレッドプーリングポリシーを使用する場合,サーバはクライアントリクエストの処理用に割り当て可能なスレッドの最大数を定義します。ワーカスレッドがクライアントリクエストごとに割り当てられますが,それはその特定のリクエストの期間だけです。リクエストが完了すると,そのリクエストに割り当てられたワーカスレッドは,クライアントから続いて要求されるリクエストを処理するために再度割り当てができるように,利用できるスレッドのプールに入れられます。

このモデルを使用すると,スレッドはサーバオブジェクトに対するリクエストトラフィックの量に基づいて割り当てられます。つまり,サーバに対し同時に多くのリクエストをする非常にアクティブなクライアントはマルチスレッドによってサービスされ,各リクエストの迅速な実行が保証されるのに対し,それほどアクティブでないクライアントは一つのスレッドを共用でき,そのリクエストは即時にサービスを受けられます。その上,スレッドはデストラクトされるのではなく再利用され,複数のコネクションに割り当てることができるので,ワーカスレッドの生成およびデストラクトに対応するオーバヘッドは減少します。

Borland Enterprise Server VisiBrokerは,同時のクライアントリクエストの数に基づいてスレッドプール中のスレッド数を動的に割り当てることでシステム資源を節約します。クライアントが非常にアクティブになると,スレッドはそのニーズに合わせて割り当てられます。スレッドがアイドルのままなら,Borland Enterprise Server VisiBrokerは現在のクライアントリクエストを満たすだけのスレッドを残してスレッドを解放します。これによって,サーバのアクティブなスレッド数は常に最適な数に保たれます。

スレッドプールのサイズはサーバアクティビティに基づいて大きくなり,個々の分散システムのニーズに合わせて実行前または実行中に設定できます。スレッドプーリングで設定できる内容は,次のとおりです。

クライアントリクエストを受信するたびに,そのリクエストを処理するためにスレッドプールからスレッドを割り当てようとします。これが最初のクライアントリクエストで,プールが空なら,スレッドが生成されます。同様に,すべてのスレッドがビジーなら,新しいスレッドが生成されてそのリクエストが処理されます。

サーバはクライアントリクエストを処理するために割り当て可能なスレッドの最大数を定義できます。利用できるスレッドがプール中になく,最大数のスレッドがすでに生成されている場合は,現在使用中のスレッドが解放されてプール中に戻されるまで,そのリクエストは待たされます。

スレッドプーリングはデフォルトのスレッドポリシーです。特に環境を設定する必要はありません。スレッドプーリングのプロパティを設定したい場合は,「8.6 ディスパッチポリシーとプロパティの設定」を参照してください。

図8‒1 スレッドのプールが利用できる

[図データ]

図8-1は,スレッドプーリングポリシーを使用したオブジェクトインプリメンテーションを示しています。その名が示すとおり,このポリシーではワーカスレッドをプールできます。

図8‒2 クライアントアプリケーション#1がリクエストを送信

[図データ]

図8-2では,クライアントアプリケーション#1がオブジェクトインプリメンテーションとのコネクションを確立して,リクエストの処理のためにスレッドが生成されます。スレッドプーリングでは,クライアントごとに一つのコネクションがあり,コネクションごとに一つのスレッドがあります。リクエストが入ってくると,ワーカスレッドはリクエストを受信します。そのワーカスレッドはもうプール中にはありません。

ワーカスレッドはスレッドプールから削除され,リクエストがあるかどうかを常に監視します。リクエストが入ってくると,そのワーカスレッドはリクエストを読み込んで,そのリクエストを適切なオブジェクトインプリメンテーションにディスパッチします。リクエストをディスパッチする前に,ワーカスレッドは次のリクエストの有無を監視するほかのワーカスレッドを一つ割り当てます。

図8‒3 クライアントアプリケーション#2がリクエストを送信

[図データ]

図8-3で示すように,クライアントアプリケーション#2が自身のコネクションを確立してリクエストを送信すると,第2のワーカスレッドが生成されます。現在はワーカスレッド3が入力リクエストの有無を監視しています。

図8‒4 クライアントアプリケーション#1が2番目のリクエストを送信

[図データ]

図8-4は,クライアントアプリケーション#1から2番目のリクエストが入ってくると,ワーカスレッド4を使用することを示しています。新しいリクエストの有無を監視するためにワーカスレッド5が生成されます。クライアントアプリケーション#1からさらにリクエストが入ってきたら,各リクエストを処理するためにワーカスレッドが次々に割り当てられます(各ワーカスレッドは,監視スレッドがリクエストを受信したあとに生成されます)。ワーカスレッドはそのタスクを完了すると,スレッドプールに戻され,クライアントからのリクエストを処理するために利用できる状態になります。