WebSphere Application Server では、TCP/IP ソケット通信メカニズムを広く使用します。
TCP/IP ソケット接続では、送受信バッファー・サイズによって受信ウィンドウが定義されます。
受信ウィンドウは、送信が可能で、送信が中断されるまで受信が禁止されるデータ・サイズを指定します。
送信データ量が大きすぎると、バッファーがオーバーランし、転送は中断されます。
データ転送の中断を制御する仕組みは、フロー制御といいます。
TCP/IP バッファーの受信ウィンドウ・サイズが小さすぎる場合は、受信ウィンドウ・バッファーが頻繁にオーバーランし、受信バッファーが空になるまでフロー制御メカニズムはデータ転送を停止します。
このタスクについて
TCP/IP が原因で、リモート・メソッドが非常に遅くなることがあります。
TCP/IP を調整するために、以下のヒントに従ってください。
プロシージャー
TCP/IP バッファー・サイズを調整します。
- まず、必ずご使用のシステムに十分なソケットを定義し、デフォルトのソケット・タイムアウト時間
(180 秒) が長すぎることのないようにします。
十分なソケットを許可するには、次のように BPXPRMxx parmlib メンバーを更新します。
- AF_INET ファイル・システムの MAXSOCKETS を十分高く設定します。
- MAXFILEPROC を十分高く設定します。
MAXSOCKETS および MAXFILEPROC を、WebSphere
トランザクション環境のスループットが低い場合は少なくとも 5000、スループットが中程度の場合は
10000、スループットが高い場合は 35000 に設定することをお勧めします。
これらのパラメーターに高い値を設定すると、ソケットまたはファイルが実際に割り振られない限り、
リソースを過度に使用することはありません。
例:
/* Open/MVS Parmlib Member */
/* CHANGE HISTORY: */
/* 01/31/02 AEK Increased MAXSOCKETS on AF_UNIX from 10000 to 50000*/
/* per request from My Developer */
/* 10/02/01 JAB Set up shared HFS */
/* KERNEL RESOURCES DEFAULT MIN MAX */
/* ======================== =================== === =========== */
.
.
MAXFILEPROC(65535) /* 64 3 65535 */
.
.
NETWORK DOMAINNAME(AF_INET) DOMAINNUMBER(2) MAXSOCKETS(30000)
.
- 次に、TCPIP プロファイル・データ・セットのポート仕様を確認し、
確実に NODELAYACKS を以下のように指定します。
PORT 8082 TCP NODELAYACKS
これを変更すると、稼働時のスループットが最大 50% 改善されることがあります
(特に、作業負荷が小さな処理を扱っている際には役に立ちます)。この設定は SSL を実行する際のパフォーマンスを良好にするために重要です。
- 必ず DNS 構成を最適にし、頻繁に使用するサーバーおよびクライアントの検索をキャッシュする必要があります。
キャッシングは、ネーム・サーバーの存続時間 (TTL) 値に関係することがあります。TTL を高く設定すると、
必ずキャッシュ・ヒットが良好になります。ただし、それを高く設定することは、
デーモンがダウンすると、ネットワークの全利用者がそれを認識するのに時間がかかることも意味します。
ご使用の DNS 構成が最適化されていることを確認する良い方法は
、oping および onslookup USS コマンドを発行することです。
妥当な時間で応答しているか確認してください。多くの場合、DNS または DNS サーバー名が正しく構成されていないと、
10 秒以上の遅延の原因となります。
- TCPIP 送受信バッファーのサイズをデフォルトの 16K から少なくとも 64K に増やします。これは、
ご使用のアプリケーションで送信しているデータで表しているもの以外の制御情報を含むバッファーのサイズです。
これを行うには、以下のように指定してください。
TCPCONFIG TCPSENDBFRSIZE 65535
TCPRCVBUFRSIZE 65535
注: バッファーに 256 K を指定することが、不合理な場合もあります。
- デフォルトの listen バックログを増やします。これは、HTTP のようなプロトコルを用いた
新しい接続のバッファー・スパイクに使用されます。
デフォルトの listen バックログの要求は 10 です。この値をより大きな値に増やすことをお勧めします。
以下に例を示します。
protocol_http_backlog=100
protocol_https_backlog=100
protocol_iiop_backlog=100
protocol_ssl_backlog=100
- finwait2 時間を削減します。 最も要求の多いベンチマークで、65K のソケットおよび
ファイル記述子を定義しても、100% 稼働させるのに十分な「空き」ソケットがないことがわかることがあります。
ソケットが異常終了で閉じている場合 (例えば、もはや必要ない場合)、直ちには使用可能になりません。
その代わり、finwait2 という状態に置かれます (これは netstat -s コマンドで示されるものです)。
フリー・プールで使用可能になる前に、しばらくの間その状態で待機します。待機時間のデフォルト値は 600 秒です。
注: ソケットの使用に問題がない場合、この設定をデフォルト値のままにしておくことをお勧めします。
z/OS V1.2 以降を使用している場合、ソケットが finwait2 状態に留まる時間を、構成ファイルで以下のように指定することによって制御することができます。
FINWAIT2TIME 60
結果
次の作業