プロキシー・サーバーのトラブルシューティング
このトピックは、プロキシー・サーバーに関して発生する可能性のある問題の解決に役立ちます。
このタスクについて
プロキシー・サーバー・エラーがジョブ・ログに記録されます。ご使用のプロキシー・サーバーで問題が発生した場合は、以下のリストを参照してください。
プロキシー・サーバー・エラーは、SystemOut.log、proxy.log、または local.log ファイルに記録されます。ご使用のプロキシー・サーバーで問題が発生した場合は、以下のリストを参照してください。
手順
- プロキシー・サーバーは正常に作成済みですが、始動できません。 SYSOUT ファイルでポートの競合について確認してください。netstat -a コマンドを使用して、プロキシー・サーバーに関連付けられたエンドポイントのうち、既に使用されているものがないか調べてください。管理コンソールで > 「サーバー」 > 「プロキシー・サーバー」 > 「<server_name>」 > 「ポート」とクリックすれば、ポートを見つけることができます。UNIX システム上で非特権ユーザーとしてプロキシー・サーバーを始動しようとして失敗する場合は、ログに以下のメッセージがないか確認します。
PROXY_HTTP_ADDRESS および PROXY_HTTPS_ADDRESS トランスポート・チェーンのポートを 1024 より大きな値に変更します。ChannelFramew E CHFW0029E: Error initializing chain HTTPS_PROXY_CHAIN because of 例外 (exception)com.ibm.wsspi.channel.framework.exception.RetryableChannelException: Permission denied TCPPort E TCPC0003E: TCP Channel TCP_7 initialization failed. The socket bind failed for host * and port 80. The port may already be in use.」
- プロキシー・サーバーは、管理ポートを介して Web コンテナーに要求を送付します。 プロキシー・サーバーは、いくつかの Web コンテナーの前に配置されます。
構成には、Web コンテナーが 9061、9081、などのデフォルト以外のポートを listen することが必要です。
このシナリオは、新規でさまざまなポートを構成内で使用することを強制する、複数のアプリケーション・サーバーが同じマシン上にある場合のデフォルトのケースです。
このシナリオでプロキシー・サーバーは、期待される 9081 のポートを使用する代わりに、9061 の管理ポートを介して、アプリケーション要求を Web コンテナーへ送付する可能性があります。
Web コンテナーの listen ポート番号を、ターゲット・アプリケーションと関連付けられた仮想ホストに追加します。 このプロセスにより、プロキシー・サーバーが正しいポート番号を介して Web コンテナーへ要求を送付することが確認されます。
- プロキシー・サーバーは始動するものの、プロキシー・サーバーのエンドポイントを介してアプリケーション・リソースにアクセスできません。 プロキシー・サーバーのエンドポイントが、アプリケーションに関連付けられた仮想ホストのホスト別名内にあることを確認します。
- プロキシー・サーバーによって、他のコア・グループが経路指定されます。 セル内のコア・グループ間にコア・グループ・ブリッジが存在するかどうか、およびブリッジとして選択されたプロセスが再始動されたかどうかを確認します。コア・グループの間にファイアウォールが存在する場合は、コア・グループのブリッジ・トラフィック用の正しいポートが開かれているかどうかを確認します。
- プロキシー・サーバーは要求を他のセルに送付することができまません。 コア・グループの
ブリッジ設定を確認します。HMGR0149E エラー・メッセージがいずれかのサーバー (通常は、コア・グループ・ブリッジとして動作するサーバー) のログに記録される場合、セルのセキュリティー設定を変更して通信できるようにする必要があります。
複数セル間のセル・セキュリティーの構成について詳しくは、トピック「Lightweight Third Party Authentication 鍵のエクスポート」を参照してください。
- プロキシーへの要求に対して、ブランク・ページを受信しました。 以下のアクションを考慮してください。
- 仮想ホストを更新します。ターゲット・アプリケーションおよびルーティング・ルールが、プロキシー・サーバーの listen ポート (デフォルトは、HTTP 80、HTTPS 443) を含む仮想ホストに割り当てられていることを確認します。プロキシー・サーバーの listen ポートをアプリケーションに追加するか、仮想ホストにルーティング・ルールを追加するか、または proxy_host を仮想ホストにします。
- 競合しているプロセスを停止します。システムで他のプロセス (Apache、IBM HTTP Server など) がプロキシー・サーバー・ポート (デフォルトは、HTTP 80、HTTPS 443) を使用して実行中でないことを確認します。この問題が発生した場合は、プロキシー・サーバーは正常に始動するように見えるものの、影響を受けた listen ポートの要求を受信できません。ご使用のシステムを以下のように確認してください。
- プロキシー・サーバーを停止します。
- netstat および ps コマンドを使用してシステムに照会し、問題のプロセスが、プロキシー・サーバーが listen しているポートを使用しているかどうかを判別します。
- 問題の原因となっているプロセスが判明した場合は、そのプロセスを停止し、システムが始動する間にそのプロセスが開始しないようにシステムを構成します。
- プロキシーのルーティングを有効にします。 プロキシー・ルーティングがアプリケーションの Web モジュールに対して有効にされていることを確認します。デフォルトでは、プロキシー・ルーティングは有効です。したがって、プロキシーのプロパティーが変更されていない場合は、この解決方法は無視してください。それ以外の場合は、アプリケーションへのルーティングのカスタマイズで、プロキシーのプロパティーの変更に関する指示を参照してください。
- 直接要求をテストします。アプリケーション・サーバーへ直接要求することによって、ターゲット・アプリケーションがインストールされていることを確認します。応答が受信されなかった場合、問題はプロキシー・サーバーではなくアプリケーション・サーバーに存在します。この場合、アプリケーション・サーバーからの応答を直接受信できる状態にしてから、プロキシー・サーバーを検証してください。
- HTTP 404 (ファイルが見つかりません) エラーをプロキシー・サーバーから受信しました。 以下のアクションを考慮してください。
- 仮想ホストを更新します。ターゲット・アプリケーションおよびルーティング・ルールが、プロキシー・サーバーの listen ポート (デフォルトは、HTTP 80、HTTPS 443) を含む仮想ホストに割り当てられていることを確認します。プロキシー・サーバーの listen ポートをアプリケーションに追加するか、仮想ホストにルーティング・ルールを追加するか、または proxy_host を仮想ホストにします。
- プロキシーのルーティングを有効にします。 プロキシー・ルーティングがアプリケーションの Web モジュールに対して有効にされていることを確認します。デフォルトでは、プロキシー・ルーティングは有効です。したがって、プロキシーのプロパティーが変更されていない場合は、この解決方法は無視してください。それ以外の場合は、アプリケーションへのルーティングのカスタマイズで、プロキシーのプロパティーの変更に関する指示を参照してください。
- 直接要求をテストします。アプリケーション・サーバーへ直接要求することによって、ターゲット・アプリケーションがインストールされていることを確認します。応答が受信されなかった場合、問題はプロキシー・サーバーではなくアプリケーション・サーバーに存在します。この場合、アプリケーション・サーバーからの応答を直接受信できる状態で、プロキシー・サーバーを検証してください。
- Secure Sockets Layer (SSL) 要求をアプリケーションまたはルーティング・ルールに発行できません。 アプリケーションの仮想ホストまたはルーティング・ルールに、プロキシー・サーバーの SSL ポート (デフォルトは 443) のホスト別名が含まれていることを確認してください。
- プロキシー・サーバーに接続できません...要求がタイムアウトになりました。 競合しているプロセスを停止します。システムで他のプロセス (Apache、IBM HTTP Server など) がプロキシー・サーバー・ポート (デフォルトは、HTTP 80、HTTPS 443) を使用して実行中でないことを確認します。この状態が発生した場合は、プロキシー・サーバーは正常に始動するように見えるものの、影響を受けた listen ポートの要求を受信できません。ご使用のシステムを以下のように確認してください。
- プロキシー・サーバーを停止します。
- netstat および ps コマンドを使用してシステムに照会し、問題のプロセスが、プロキシー・サーバーが listen しているポートを使用しているかどうかを判別します。
- 問題の原因となっているプロセスが判明した場合は、そのプロセスを停止し、システムが始動する間にそのプロセスが開始しないようにシステムを構成します。
- HTTP エラー (404 など) が発生したとき、エラー・ページ・アプリケーションからの応答が受信されませんでした。 エラー・ページ URI が正しく入力されていることを確認してください。 また、HTTP エラー応答をバックエンド・サーバーから処理している場合は、「Handle remote errors」オプションが選択されていることを確認してください。詳細情報については、カスタム・エラー・ページ・ポリシーの概要 および プロキシー・サーバーの設定の『custom error page policy』セクションを参照してください。
- プロキシー・サーバーをトレースするには、どのパッケージを有効にすればよいでしょうか。 すべてのトレースに以下のパッケージがすべて必要というわけではありませんが、特定できない場合は、以下をすべて使用します。
- *=info
- WebSphere Proxy=all
- GenericBNF=all
- HAManager=all
- HTTPChannel=all
- TCPChannel=all
- WLM*=all
- DCS=all
- ChannelFrameworkService=all
- com.ibm.ws.dwlm.*=all
- com.ibm.ws.odc.*=all
- SSL のオン/オフ・ロードを有効にする手順 SSL のオン/オフ・ロードは、 管理コンソールのトランスポート・プロトコルとして参照されており、 トランスポート・プロトコルは、Web モジュールのプロパティーです。Web モジュール・プロパティーの構成方法については、アプリケーションへのルーティングのカスタマイズを参照してください。トランスポート・プロトコルは、ルーティング・ルールで指定されている汎用サーバー・クラスターに継承されるため、ルーティング・ルールに対して、SSL のオン/オフ・ロードまたはトランスポート・プロトコル・プロパティーは存在しません。
- IBM HTTP Server または Web サーバー・プラグインがフロントとなっている場合、 プロキシー・サーバー用のポートを仮想ホストに追加しなくても済むようにプロキシー・サーバーを構成するには、どのようにしたらよいでしょうか。 プロキシー・サーバーによって、製品が追加するプライベート・ヘッダーなどの、要求に含まれるセキュリティー関連の情報が信頼されるようにするには、プロキシー・サーバーの信頼できるセキュリティー・プロキシー・リストに要求のオリジネーターを追加します。 例えば、プロキシー・サーバーに要求を送信する IBM HTTP Server または Web サーバー・プラグインを、 プロキシー・サーバーの信頼できるセキュリティー・プロキシーのリストに追加します。 その後、Web サーバー・プラグインは、製品が追加したプライベート・ヘッダー情報を送信することができます。この中には、要求の仮想ホスト情報が含まれています。 Web サーバー・プラグインまたはいずれかのクライアントからのこれらのプライベート・ヘッダーがプロキシーによって信頼されない場合は、プロキシー・サーバーによって、サーバー独自のプライベート・ヘッダーが追加されます。このプライベート・ヘッダーは、プロキシー・サーバーの HTTP ポートと HTTPS ポートを仮想ホストに追加するよう要求します。 一般に、プロキシー・サーバーで Web サーバー・プラグインを使用する場合は、プロキシー・サーバーをバックエンド・サーバーとして使用することを意図しています。 したがって、プロキシー・サーバーのポートを公開せずに済むように、信頼できるセキュリティー・プロキシーとしてプラグインを追加する必要があります。 プロキシー・サーバーで使用する Web サーバー・プラグインの構成について詳しくは、プラグインからプロキシー・サーバーへの要求のルーティングを参照してください。 信頼できるセキュリティー・プロキシーのセットアップについて詳しくは、プロキシー・サーバーの設定を参照してください。
- プロキシー・サーバーがストレスによってハングしているか、「Too Many Files Open」例外が ffdc または SystemErr.log に表示されています。 接続負荷が大きいために、ファイル・システム記述子の数が使用し尽され、プロキシー・サーバーがハングしてソケットを開くことができないため、ffdc ディレクトリーまたは SystemError.log ファイル内に「Too Many Files Open」例外がドロップされる場合があります。
この問題を軽減するには、オペレーティング・システム・レベルおよびプロキシー・サーバー・レベルで、以下のパラメーターのうち 1 つ以上を変更し、プロキシー・サーバーの接続の使用を最適化します。
Windows 2003、および XP のオペレーティング・システム調整
- TcpTimedWaitDelay - TCP/IP がクローズされた接続を解放し、そのリソースを再利用するまでの経過時間を判断します。クローズと解放との間隔は、TIME_WAIT 状態、またはセグメントの最大存続時間の 2 倍 (2MSL) 状態として知られています。この期間中は、新しく接続を確立するよりも、クライアントとサーバーへの接続を再オープンしたほうが、負担が軽くて済みます。 この項目の値を減らすと、TCP/IP はクローズされた接続を迅速に解放して、より多くのリソースを新しい接続に提供することができます。実行中のアプリケーションが、接続の迅速な解放、または新しい接続の作成を必要とする場合、あるいは TIME_WAIT 状態の接続が多すぎるためにスループットが低い場合は、このパラメーターを調整してください。
以下のようにして、この値を表示または設定します。
- regedit コマンドを使用して、HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥ Services¥TCPIP¥Parameters レジストリー・サブキーにアクセスし、TcpTimedWaitDelay という名前の新しい REG_DWORD 値を作成します。
- この値を、16 進数の 0x0000001e に当たる 10 進数の 30 に設定します。 この値は、待ち時間を 30 秒に設定します。
- システムを停止して再始動します。
情報 値 デフォルト値 0xF0 です。この値は待ち時間を 240 秒 (4 分) に設定します。 推奨値 最小値は 0x1E で、この値は待ち時間を 30 秒に設定します。 - MaxUserPort - アプリケーションが使用可能なユーザー・ポートをシステムに要求したときに、TCP/IP が割り当てることのできる最高のポート番号を決定します。以下のようにして、この値を表示または設定します。
- regedit コマンドを使用して、HKEY_LOCAL_MACHINE¥SYSTEM¥CurrentControlSet¥ Services¥TCPIP¥Parameters レジストリー・サブキーにアクセスし、MaxUserPort という名前の新しい REG_DWORD 値を作成します。
- この値を最小でも 10 進数の 32768 に設定します。
- システムを停止して再始動します。
情報 値 デフォルト値 なし 推奨値 最小でも 10 進数の 32768。
- TcpTimedWaitDelay - TCP/IP がクローズされた接続を解放し、そのリソースを再利用するまでの経過時間を判断します。クローズと解放との間隔は、TIME_WAIT 状態、またはセグメントの最大存続時間の 2 倍 (2MSL) 状態として知られています。この期間中は、新しく接続を確立するよりも、クライアントとサーバーへの接続を再オープンしたほうが、負担が軽くて済みます。 この項目の値を減らすと、TCP/IP はクローズされた接続を迅速に解放して、より多くのリソースを新しい接続に提供することができます。実行中のアプリケーションが、接続の迅速な解放、または新しい接続の作成を必要とする場合、あるいは TIME_WAIT 状態の接続が多すぎるためにスループットが低い場合は、このパラメーターを調整してください。
Linux のオペレーティング・システム調整
- timeout_timewait パラメーター - TCP/IP がクローズされた接続を解放し、そのリソースを再利用するまでの経過時間を判断します。クローズと解放との間隔は、TIME_WAIT 状態、またはセグメントの最大存続時間の 2 倍 (2MSL) 状態として知られています。この期間中は、新しく接続を確立するよりも、クライアントとサーバーへの接続を再オープンしたほうが、負担が軽くて済みます。 この項目の値を減らすと、TCP/IP はクローズされた接続を迅速に解放して、より多くのリソースを新しい接続に提供することができます。実行中のアプリケーションが、接続の迅速な解放、または新しい接続の作成を必要とする場合、あるいは TIME_WAIT 状態の接続が多すぎるためにスループットが低い場合は、このパラメーターを調整してください。
timeout_timewait パラメーターを 30 秒に設定する以下のコマンドを発行して、この値を表示または設定します。
echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
- Linux ファイル記述子 (ulimit) - サポートされるオープン・ファイルの数を指定します。
ほとんどのアプリケーションについては、通常はデフォルト設定のままで十分です。
このパラメーターに設定した値が低すぎると、ファイル・オープン・エラー、メモリー割り振り失敗、または接続確立エラーが表示される場合があります。
この値を表示または設定するには、各種シェルの構文について、UNIX のリファレンス・ページの ulimit コマンドを参照してください。 KornShell シェル (ksh) で ulimit コマンドを 65535 に設定するには、ulimit -n 65535 コマンドを実行します。システム・リソースの制限についてすべての現行値を表示するには、ulimit -a コマンドを使用します。
情報 値 デフォルト値 1024 推奨値 65535
- timeout_timewait パラメーター - TCP/IP がクローズされた接続を解放し、そのリソースを再利用するまでの経過時間を判断します。クローズと解放との間隔は、TIME_WAIT 状態、またはセグメントの最大存続時間の 2 倍 (2MSL) 状態として知られています。この期間中は、新しく接続を確立するよりも、クライアントとサーバーへの接続を再オープンしたほうが、負担が軽くて済みます。 この項目の値を減らすと、TCP/IP はクローズされた接続を迅速に解放して、より多くのリソースを新しい接続に提供することができます。実行中のアプリケーションが、接続の迅速な解放、または新しい接続の作成を必要とする場合、あるいは TIME_WAIT 状態の接続が多すぎるためにスループットが低い場合は、このパラメーターを調整してください。
timeout_timewait パラメーターを 30 秒に設定する以下のコマンドを発行して、この値を表示または設定します。
AIX® のオペレーティング・システム調整
- TCP_TIMEWAIT - TCP/IP がクローズされた接続を解放し、そのリソースを再利用するまでの経過時間を判断します。クローズと解放との間隔は、TIME_WAIT 状態、またはセグメントの最大存続時間の 2 倍 (2MSL) 状態として知られています。この期間中は、新しく接続を確立するよりも、クライアントとサーバーへの接続を再オープンしたほうが、負担が軽くて済みます。 この項目の値を減らすと、TCP/IP はクローズされた接続を迅速に解放して、より多くのリソースを新しい接続に提供することができます。実行中のアプリケーションが、接続の迅速な解放、または新しい接続の作成を必要とする場合、あるいは TIME_WAIT 状態の接続が多すぎるためにスループットが低い場合は、このパラメーターを調整してください。
TCP_TIMEWAIT 状態を 15 秒に設定する以下のコマンドを発行して、この値を表示または設定します。
/usr/sbin/no -o tcp_timewait =1
- AIX ファイル記述子 (ulimit) - 許可されるオープン・ファイルの数を指定します。
ほとんどのアプリケーションについては、通常はデフォルト設定のままで十分です。
このパラメーターに設定した値が低すぎると、ファイルを開いたとき、または接続を確立したときにエラーが発生し、メモリー割り振りエラーが表示される場合があります。
WebSphere® Application Server でリソースが不足しないように、WebSphere Application Server プロセスを実行するユーザー・アカウントについてリソースの制限 (ulimit) を除去します。以下のように ulimit 設定を変更して、この値を表示または設定します。
- コマンド・ウィンドウを開きます。
- smitty users と入力し、AIX 構成プログラムを開きます。
- ユーザーの「Change」または「Show Characteristics」を選択します。
- WebSphere Application Server を実行するユーザー・アカウントの名前を入力します。
- Enter キーを押します
- 以下の設定値を指示された値に変更します。
情報 値 Soft FILE Size -1 Soft CPU Time -1 Soft STACK Size -1 Soft CORE File Size -1 Hard FILE Size -1 Hard CPU Time -1 Hard STACK Size -1 Hard CORE File Size -1 - Enter キーを押して、変更を保存します。
- ログアウトし、ご使用のアカウントでログインします。
- 製品を再始動します。
情報 値 デフォルト値 2000 推奨値 無制限
- TCP_TIMEWAIT - TCP/IP がクローズされた接続を解放し、そのリソースを再利用するまでの経過時間を判断します。クローズと解放との間隔は、TIME_WAIT 状態、またはセグメントの最大存続時間の 2 倍 (2MSL) 状態として知られています。この期間中は、新しく接続を確立するよりも、クライアントとサーバーへの接続を再オープンしたほうが、負担が軽くて済みます。 この項目の値を減らすと、TCP/IP はクローズされた接続を迅速に解放して、より多くのリソースを新しい接続に提供することができます。実行中のアプリケーションが、接続の迅速な解放、または新しい接続の作成を必要とする場合、あるいは TIME_WAIT 状態の接続が多すぎるためにスループットが低い場合は、このパラメーターを調整してください。
TCP_TIMEWAIT 状態を 15 秒に設定する以下のコマンドを発行して、この値を表示または設定します。
オペレーティング・システムの HP-UX 向けの調整
HP-UX nfile カーネル・パラメーター - 指定された時刻にシステム上で開くことができるファイルの最大数を指定します。十分に大きな数値を指定しないと、システムの処理能力が制限されます。
HP-UX ninode カーネル・パラメーター - メモリーに存在できる、開いている inode の最大数を指定します。 開いている inode は、固有のオープン・ファイルそれぞれに関連付けられています。 このため、ninode パラメーターに指定する値は、同時に開いておく必要がある固有のファイルの数より大きくする必要があります。
Solaris のオペレーティング・システム調整
- Solaris ファイル記述子 (ulimit) - サポートされるオープン・ファイルの数を指定します。このパラメーターに指定した値が小さすぎると、ファイル・オープン・エラー、メモリー割り振り障害、または接続確立エラーが表示される場合があります。この値を表示または設定するには、各種シェルの構文について、UNIX のリファレンス・ページの ulimit コマンドを参照してください。
- システム・リソースに対するすべての制限の現行値を表示するには、ulimit -a コマンドを使用します。
- KornShell シェル (ksh) で ulimit コマンドを 65535 に設定するには、ulimit -n 65535 コマンドを実行します。
- 1 つのプロセスで開くことができるファイルの最大数は、グローバル・カーネル制限の rlim_fd_max および rlim_fd_cur 設定によっても影響されます。 /etc/system ファイルのこれらの設定の値を増やす必要がある場合があります。
Solaris 10 は、カーネル・パラメーターの設定のための新しい手段を提供します。 Solaris 10 のファイル記述子のカーネル・パラメーターの最大数に新しい制限を指定するには、以下のコマンドのいずれかを発行します。- 現在のシェル・セッションの値を変更するには、以下のコマンドを実行します。
prctl -n process.max-file-descriptor -r -v 65535 $$
- 変更をシステム全体に適用するには、以下のコマンドを実行します。
projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)' system
このコマンドを発行すると、すべてのユーザーの設定、およびすべてのプロジェクトが変更されるため、注意が必要です。
- ユーザー root によって所有されるすべてのプロジェクトの値を変更するには、以下のコマンドを実行します。
projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)' user.root
- 非 root ユーザーによって所有されるすべてのプロジェクトの値を変更するには、以下のコマンドを実行します。
projmod -sK 'process.max-file-descriptor=(privileged,65535,deny)' user.username
- TCP_TIME_WAIT_INTERVAL - クローズされた接続制御ブロックを保持しておく時間を TCP/IP に通知します。アプリケーションが TCP/IP 接続を完了すると、指定された時間だけ制御ブロックが保持されます。
接続率が高い場合は、TCP/IP 接続のバックログ分が多くなり、サーバーのパフォーマンスが低下します。
特定のピーク期間に、サーバーが停止することがあります。
サーバーが停止した場合、netstat コマンドを使用すると、HTTP サーバーに対してオープンされたソケットの多くが、CLOSE_WAIT または FIN_WAIT_2 状態になっていることが分かります。
目に見える遅延が最大で 4 分間にもわたって発生する場合があり、その間サーバーは応答をまったく送信しませんが、システム・プロセスのアクティビティー全体での CPU 使用率は高い状態のままです。この値を表示または設定するには、get コマンドを使用して現在の間隔を判別し、set コマンドを使用して間隔を 30 秒に指定します。以下に例を示します。
ndd -get /dev/tcp tcp_time_wait_interval ndd -set /dev/tcp tcp_time_wait_interval 30000
情報 値 デフォルト値 240000 ミリ秒、つまり 4 分です。 推奨値 60000 ミリ秒
- Solaris ファイル記述子 (ulimit) - サポートされるオープン・ファイルの数を指定します。このパラメーターに指定した値が小さすぎると、ファイル・オープン・エラー、メモリー割り振り障害、または接続確立エラーが表示される場合があります。この値を表示または設定するには、各種シェルの構文について、UNIX のリファレンス・ページの ulimit コマンドを参照してください。
- プロキシー・サーバー調整
- パーシスタント要求 - パーシスタント要求とは、既存の TCP 接続を使用して送信される要求です。TCP 接続を使用してクライアントから受信される要求の数を増やすことにより、パフォーマンスを最大化できます。この値は、Web ページ +1 の、例えば GIF などの
組み込みオブジェクトの最大数を表します。
この値を表示または設定するには、WebSphere Application Server の管理コンソールで「サーバー」 > 「プロキシー・サーバー」 > 「server_name」 > 「プロキシー・サーバーのトランスポート」 > 「HTTP_PROXY_CHAIN/HTTPS_PROXY_CHAIN」とクリックします。
情報 値 デフォルト値 100 推奨値 Web ページ + 1 に組み込まれるオブジェクトの最大数を表す値。 - アウトバウンド接続プール・サイズ - プロキシー・サーバーはターゲット・サーバーへのアウトバウンド接続をプールし、プールに常駐する接続の数は構成可能です。接続のプールが使い尽くされたか、または空の場合は、プロキシー・サーバーによってターゲット・サーバーへの新規接続が作成されます。並行負荷が高い場合は、パフォーマンスを最適化するために、接続のプール・サイズは、予想される並行クライアント負荷の値まで増やす必要があります。
この値を表示または設定するには、WebSphere Application Server の管理コンソールで「サーバー」 > 「プロキシー・サーバー」 > 「server_name」 > 「プロキシー・サーバーのトランスポート」 > 「HTTP プロキシー・サーバー設定」とクリックします。「コンテンツ・サーバー接続」セクションで、「サーバーあたりの最大接続数」フィールドの値を接続するクライアント数の予想最大数より大きな値にします。変更を保存し、プロキシー・サーバー・ノードにその変更を同期化し、プロキシー・サーバーを再始動します。
情報 値 推奨値 並行するクライアントの予想される負荷と整合する値 - アウトバウンド要求タイムアウト - 多くの場合、プロキシー・サーバーがフロントとなっているバックエンド・アプリケーション・サーバーの負荷は高く、応答時間が適切ではありません。したがって、プロキシー・サーバー上の接続が、バックエンド・アプリケーション・サーバーからの応答の待機のために拘束される可能性があります。
ターゲット・サーバーからの応答をプロキシー・サーバーが待機する時間を構成することにより、この状態を軽減します。これが、アウトバウンド要求タイムアウト値です。
プロキシー・サーバーが、低速なバックエンド・アプリケーション・サーバーを待機する時間を管理することにより、接続が解放されて速度が向上し、他の要求を処理するために接続を使用できるようになります。この値を表示または設定するには、管理コンソールで、「サーバー」 > 「サーバー・タイプ」 > 「WebSphere プロキシー・サーバー」 > 「proxy_server_name」 > 「HTTP プロキシー・サーバー設定」とクリックします。「コンテンツ・サーバー接続」セクションで、アウトバウンド要求のタイムアウトの値をクライアントの視点から許容できる応答時間を表す値に設定します。
情報 値 デフォルト値 120 推奨値 クライアントの視点から許容できる応答時間を表す値。
- パーシスタント要求 - パーシスタント要求とは、既存の TCP 接続を使用して送信される要求です。TCP 接続を使用してクライアントから受信される要求の数を増やすことにより、パフォーマンスを最大化できます。この値は、Web ページ +1 の、例えば GIF などの
組み込みオブジェクトの最大数を表します。
サブトピック
プロキシー・サーバーを介した要求のルーティングおよびワークロード管理のトラブルシューティング
このセクションでは、プロキシー・サーバーを介した要求のトラフィックのフローに対するトラブルシューティングの方法について説明します。


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tjpx_troubproxy
ファイル名:tjpx_troubproxy.html