トランスポート・チャネル・サービスは、HTTP および JMS 要求の
クライアント接続と I/O 処理を管理します。
これらの I/O サービスは Java™ で使用可能な非ブロッキング I/O (NIO) 機能を基にしています。これらのサービスは、WebSphere Application Server 要求処理に拡張が容易な基盤を提供します。Java NIO ベースのアーキテクチャーには、パフォーマンス、スケーラビリティー、およびエンド・ユーザーの使用可能度に関する制限があります。
したがって、真の非同期入出力の統合が実現されます。これにより、使用可能度が大幅に高まり、I/O 処理の複雑さが緩和され、実行する必要があるパフォーマンス調整作業が削減されます。
このタスクについて
新規トランスポート・チャネル・サービスの主なフィーチャーには、以下のものがあります。
- スケーラビリティー。WebSphere Application Server は多くの並行する要求を処理することができます。
- 非同期要求処理。Web コンテナー・スレッドにクライアント要求の多対 1 マッピングを提供します。
- リソース共有および分離。スレッド・プールを Web コンテナーとメッセージング・サービス間で共有することができます。
- 使用可能度の改良
- オートノミック調整と構成機能の取り込み
トランスポート・チェーンと関連する 1 つ以上のトランスポート・チャネルで
設定のデフォルト値を変更すると、そのチェーンのパフォーマンスを改善することができます。
図 1. トランスポート・チャネル・サービス
プロシージャー
- TCP トランスポート・チャネルの設定を調整します。 管理コンソールで、
「サーバー」>「アプリケーション・サーバー」>「server_name」>「ポート」をクリックします。
次に、適切なポートで「関連トランスポートの表示」をクリックします。
- プロパティーを変更するトランスポート・チェーンを選択します。
- そのチェーンに定義した TCP トランスポート・チャネルをクリックします。
- 「最大のオープン接続数」パラメーター・セットをデフォルト値のままにします。
このパラメーターは、サーバーで使用可能な最大接続数を制御します。
許可されている最大接続数である、デフォルト値の 20000 のままにしておく必要があります。
デフォルトで、トランスポート・チャネル・サービスは、
多数のクライアント接続数を管理するため、調整は必要ありません。
- データがクライアントに書き込まれることなくクライアント接続がクローズされる場合は、
「非活動タイムアウト」パラメーターに指定された値を変更します。
このパラメーターは、サーバーで使用可能な最大接続数を制御します。
TCP トランスポート・チャネルは、新規接続を受信すると、TCP トランスポート・チャネルの上の
プロトコル固有のチャネルに接続をディスパッチするのに十分なデータを受信するまで待ちます。
「非活動タイムアウト」パラメーターに指定した時間内に
十分なデータを受信しなかった場合、TCP トランスポート・チャネルは接続をクローズします。
このパラメーターのデフォルト値は 60 秒であり、この値はほとんどのアプリケーションに適しています。
ワークロードが多くの接続を必要とし、これらの接続が 60 秒以内にすべて処理されない場合は、
このパラメーターに指定した値を増やす必要があります。
- 特定の HTTP ポートにスレッド・プールを割り当てます。 各 TCP トランスポート・チャネルは、特定のスレッド・プールに割り当てられます。
スレッド・プールは、1 つ以上の TCP トランスポート・チャネルとその他のコンポーネントの間で共有することができます。
TCP トランスポート・チャネルのデフォルト設定では、
すべての HTTP ベースのトラフィックが WebContainer スレッド・プールに割り当てられ、
その他すべてのトラフィックは Default のスレッド・プールに割り当てられています。
スレッド・プールのプルダウンを使用して、各 TCP トランスポート・チャネルに
特定のスレッド・プールを割り当てます。
このパラメーターのデフォルト設定では、すべての HTTP ベースの
トラフィックが WebContainer スレッド・プールに割り当てられ、
その他すべてのトラフィックは Default のスレッド・プールに割り当てられています。
(追加のスレッド・プールの作成方法について
は、スレッド・プール・コレクション
を参照してください。)
- スレッド・プールのサイズを調整します。
デフォルトでは、
スレッド・プールのスレッド数は、最小で 10、最大で 50 となっています。
これらの値を調整するには、「Thread pools」>「threadpool_name」をクリックし、
そのスレッド・プールの「最小サイズ」および「最大サイズ」パラメーターに指定された値を調整します。
通常のアプリケーションは、プロセッサーごとに 10 より多いスレッドを必要としません。
ただし、非常に遅いバックエンド要求など、一部がオフ・サーバー状態となり、そのバックエンド要求が
完了するまでサーバー・スレッドが待機するような場合は例外です。
このような場合、通常は CPU 使用は低く、ワークロードを増やしても CPU スループットは増加しません。
スレッド・ダンプは、バックエンド・リソースに対するコールアウトでのほとんどすべてのスレッドを表示します。
この状態で、バックエンドが正しく調整されている場合、スループットが改善されるまでプールの最小スレッド数を増やすと、
スレッド・ダンプは、バックエンド呼び出しを除くランタイムの他の領域のスレッドを表示します。
必要なパラメーターである「Grow」の設定値は、バックエンドが長時間ハングする傾向にない限り、
変更しないでください。
この状態は、すべてのランタイム・スレッドが、ハングしているバックエンドに関係のない
他の作業を処理する代わりに、バックエンドを待機してブロックされていることを示している場合があります。
- HTTP トランスポート・チャネルの設定を調整します。 管理コンソールで、
「サーバー」>「アプリケーション・サーバー」>「server_name」>「ポート」をクリックします。
次に、適切なポートで「関連トランスポートの表示」をクリックします。
- プロパティーを変更するトランスポート・チェーンを選択します。
- そのチェーンに定義した HTTP トランスポート・チャネルをクリックします。
- HTTP キープアライブを調整します。 「ユーザー・パーシスタント
(キープアライブ) 接続」設定は、接続を要求間でオープンのままにするかどうかを制御します。
接続をオープンのままにすると、ワークロードのクライアントが複数の要求を送信する場合に、
ソケットのセットアップと取り壊しの手間を省くことができます。
デフォルト値は true で、ほとんどの場合に最適な設定値です。
クライアントがかなり長い時間をかけて
単一の要求のみを送信する場合は、HTTP トランスポート・チャネルに後から接続をクローズするようタイムアウトを
セットアップするよりも、このオプションを使用不可にし、すぐに接続をクローズすることをお勧めします。
- 「最大のパーシスタント要求数」パラメーターに指定された値を変更し、
接続のクローズ前に接続を介して流すことができる要求数を増やします。
「Use persistent connections」オプションを使用可能にすると、
「最大のパーシスタント要求数」パラメーターは、接続のクローズ前に接続を介して流すことができる要求数を制御します。
デフォルト値は 100 です。
この値は、ほとんどのクライアント (すべてでない場合) が同じセッション中に複数の要求を行うときに、
クライアントの接続が常にオープンになるような値に設定する必要があります。
このパラメーターを適切に設定することによって、ソケットの不必要なセットアップと取り壊しを
除去することができます。
クライアントが決してソケットをクローズしないテスト・シナリオ、またはソケットが常に
アプリケーション・サーバーの前のプロキシーまたは Web サーバーであるテスト・シナリオでは、
値 -1 は単一の接続を介した要求数を制限する処理を使用不可にします。
パーシスタント・タイムアウトは、一部のアイドル状態ソケットをシャットダウンして、
サーバーでのオープン・ソケットがなくならないようにします。
- 「パーシスタント・タイムアウト」パラメーターに指定された値を変更して、
接続が非活動によってクローズされるまでオープンされている時間を長くします。
「パーシスタント・タイムアウト」パラメーターは、
接続に活動がないためクローズされるまで、その接続がオープンされている時間の長さを制御します。
デフォルト値は 30 秒です。このパラメーターは、ほとんどのクライアントが要求を行う際に
使用可能な接続を取得できるように、十分なオープン接続を保持する値に設定する必要があります。
- クライアントがデータを送信するのに 60 秒より長くかかったため、
要求を完了する際に問題が起きた場合は、
「読み取りタイムアウト」パラメーターに指定された値を変更します。
一部のクライアントは、要求の一部としてデータを送信する間、60 秒より長く一時停止します。
要求を完了できるようにするには、このパラメーターに指定された値を、
クライアントがデータ送信を完了するのに十分な時間 (秒) に変更します。
この値を変更する際には、サーバーに対してクライアントが未完了のデータを送信し、
そのためにリソース (ソケット) が長時間使用されることのないように注意してください。
- 一部のクライアントで、そのクライアントに書き込まれるデータの受信に 60 秒より
長くかかる場合は、「書き込みタイムアウト」パラメーターに指定された値を変更してください。
一部のクライアントは遅いため、送信されるデータを受信するのに 60 秒より長い時間が必要です。
クライアントがすべてのデータを確実に取得できるようにするには、
このパラメーターの値を、すべてのデータを受信するのに十分な時間 (秒) に変更します。
この値を変更する際に、サーバーを悪意のあるクライアントから保護することに注意してください。
- Web コンテナー・トランスポート・チャネル設定を調整します。 管理コンソールで、
「サーバー」>「アプリケーション・サーバー」>「server_name」>「ポート」をクリックします。
次に、適切なポートで「関連トランスポートの表示」をクリックします。
- プロパティーを変更する必要があるトランスポート・チェーンを選択します。
- そのチェーンに定義した Web コンテナー・トランスポート・チャネルをクリックします。
- 複数の書き込みがクライアントに対する応答を処理するために必要な場合、
「書き込みバッファー・サイズ」パラメーターに指定された値を、クライアントに適した値に変更します。
「書き込みバッファー・サイズ」パラメーターは、
処理のために要求を送信する前に、Web コンテナーがバッファーに入れるスレッドごとのデータの最大量を制御します。
デフォルト値は 32768 バイトであり、この値はほとんどのアプリケーションに適しています。
応答のサイズが書き込みバッファーのサイズより大きい場合、応答はチャンク化され、
複数の TCP 書き込みに書き込まれます。
このパラメーターに指定された値を変更する必要がある場合は、
新規の値がほとんどの要求を単一の書き込みに書き出されることを確認します。
このパラメーターに適切な値を判別するには、戻されたページ・サイズを見て、HTTP ヘッダーのために
数バイトを追加します。
- バウンド・バッファーの設定を調整します。
バウンド・バッファーのデフォルト・パラメーターはほとんどの環境に対して最適ですが、特定の状況および一部のオペレーティング・システムでは、デフォルト値を変更してパフォーマンスを強化する必要があります。
バウンド・バッファーのパラメーターを変更すると、パフォーマンスが低下することがあります。
したがって、バウンド・バッファーのパラメーターを変更する前に、Web コンテナーや ORB スレッド・プールなど、その他の関連領域を調整する必要があります。
バウンド・バッファーのパラメーターを変更するには、次のようにします。
- 管理コンソールで、「サーバー」 > 「アプリケーション・サーバー」 > 「server」をクリックします。
- 「サーバー・インフラストラクチャー」の下で、
「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」をクリックします。
- 「汎用 JVM 引数」フィールドで、以下のパラメーターのうち 1 つを指定します。
- 「適用」または「OK」をクリックします。
- 「名前」フィールドに以下のカスタム・プロパティーの 1 つを入力し、「値」フィールドに適切な値を入力してから、「適用」をクリックしてカスタム・プロパティーおよびその設定を保存します。
- com.ibm.ws.util.BoundedBuffer.spins_take=value
Web コンテナー・スレッドを中断してエンキューするまでに、このスレッドを使用してバッファーから要求を検索できる回数を指定します。
このパラメーターを使用すると、検索試行に失敗した場合のコストと、
スレッドを中断してから PUT 操作に応答して再度有効にするコストをトレードオフすることができます。
デフォルト: |
4 |
推奨: |
任意の負でない整数値を使用できます。実際は、2 から 8 の整数を使用すると、パフォーマンスが最適化されます。
|
使用法: |
com.ibm.ws.util.BoundedBuffer.spins_take=6。スレッドを中断するまでの試行回数は、6 回です。
|
- com.ibm.ws.util.BoundedBuffer.yield_take=true または false。
バッファーから要求を取得するための作業を所定の回数だけ実行した場合に、CPU がその他のスレッドに振り分けられるように指定します。
通常は、試行回数を少なくすることをお勧めします。
デフォルト: |
false |
推奨: |
各プラットフォームごとに、効果は異なります。 |
使用法: |
com.ibm.ws.util.BoundedBuffer.spins_take=ブール値 |
- com.ibm.ws.util.BoundedBuffer.spins_put=値
InboundReader スレッドを中断してエンキューするまでに、このスレッドが要求をバッファーに格納する回数を指定します。
この値を使用すると、要求をバッファーに格納する反復試行 (通常は失敗する試行) のコストと、
スレッドを中断してから取得操作に応答して再度有効にするコストをトレードオフすることができます。
デフォルト: |
4 |
推奨: |
任意の負でない整数値を使用できます。実際は、2 から 8 の整数を使用すると、パフォーマンスが最適化されます。
|
使用法: |
com.ibm.ws.util.BoundedBuffer.spins_put=6。スレッドを中断するまでの試行回数は、6 回です。
|
- com.ibm.ws.util.BoundedBuffer.yield_put=true または false。
バッファーに要求を格納するための作業を所定の回数だけ実行した場合に、CPU がその他のスレッドに振り分けられるように指定します。
通常は、試行回数を少なくすることをお勧めします。
デフォルト: |
false |
推奨: |
各プラットフォームごとに、効果は異なります。 |
使用法: |
com.ibm.ws.util.BoundedBuffer.yield_put=ブール値 |
- com.ibm.ws.util.BoundedBuffer.wait=ミリ秒数
バッファーが完全にいっぱいの場合、またはバッファーが空の場合に、要求を不必要に遅延する最大期間をミリ秒単位で指定します。
デフォルト: |
10000 ミリ秒 |
推奨: |
通常は、値に 10000 ミリ秒を指定すると適切に機能します。まれに、バッファーがいっぱい、または空の場合に、より小さな値を指定すると、要求が適切なタイミングで確実に処理されますが、通常はパフォーマンスが低下します。
|
使用法: |
com.ibm.ws.util.BoundedBuffer.wait=8000。要求には最大 8000 ミリ秒の不必要な遅延が発生することがあります。 |
- 「適用」をクリックし、「保管」をクリックして、これらの変更を保管します。