アプリケーション・サーバーの調整
この製品には、相互に関連のあるコンポーネントが含まれています。それらは、エンドツーエンド e-business アプリケーションのカスタム・ニーズをサポートするように、協調しながら調整する必要があります。
このタスクについて
相互に関連付けられたコンポーネントから成るこのグループはキューイング・ネットワークと呼ばれます。このキューイング・ネットワークは、
システム全体の安定性を維持しながら、最大のスループットを達成するのに役立ちます。
以下のステップでは、アプリケーション・サーバーのパフォーマンスを向上させるためのさまざまな調整タスクについて説明します。これらのいずれかのアプリケーション・サーバー設定を実装するよう選択できます。これらのステップは任意の順序で実行できます。
手順
- アプリケーション・サーバーのパフォーマンスを改善するための開始点として、
applyPerfTuningTemplate.py を実行します。
Python ベースの調整スクリプト applyPerfTuningTemplate.py を そのテンプレート・ファイルの 1 つとともに使用して、推奨されるパフォーマンス・チューニング設定を 適用することができます。スクリプト、およびこれらのテンプレート・ファイルはWAS_HOME/bin ディレクトリーにあります。
- オブジェクト・リクエスト・ブローカーの調整。 オブジェクト・リクエスト・ブローカー (ORB) は、
Internet InterORB Protocol (IIOP) を使用して、クライアントとサーバーの間の対話を管理します。
また、ネットワーク分散環境でサーバーから受信するクライアント要求および応答をサポートします。
以下のパラメーターを使用して、ORB を調整できます。
- 『オブジェクト・リクエスト・ブローカー・サービス設定』に記載されているように、 「参照による受け渡し (com.ibm.CORBA.iiop.noLocalCopies)」を設定します。
『オブジェクト・リクエスト・ブローカー・サービス設定』に 記載されているように、「接続キャッシュ最小 (com.ibm.CORBA.MaxOpenConnections)」を設定します。
スレッド・プール設定に関するトピックに記載されているように、 「最大サイズ」を設定します。
オブジェクト・リクエスト・ブローカーの カスタム・プロパティーに関する情報に記載されているように、「com.ibm.CORBA.ServerSocketQueueDepth」を設定します。
- オブジェクト・リクエスト・ブローカーの カスタム・プロパティーに関する情報に記載されているように、「ibm.CORBA.FragmentSize」を設定します。
これらのパラメーターを使用して ORB を調整する際のヒント については、オブジェクト・リクエスト・ブローカーのチューニング・ガイドラインに関する情報を参照してください。
- XML パーサー定義の調整。
- 説明: ${app_server_root}/jre/lib ディレクトリーの jaxp.properties および xerces.properties ファイルに XML パーサーの定義を追加して、サーバーが素早く始動できるようにします。Xerces の新規バージョンが提供されると、XMLParserConfiguration の値が変わることがあります。
- 表示または設定の方法: 両方のファイルに以下の行を挿入します。
JDK インストールに付属の jre/lib/jaxp.properties ファイルおよび jre/lib/xerces.properties ファイルを参照することもできます。これらのサンプル・ファイルは、常に推奨設定を含んでいます。javax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl javax.xml.parsers.DocumentBuildFactory=org.apache.xerces.jaxp. DocumentBuilderFactoryImpl org.apache.xerces.xni.parser.XMLParserConfiguration=org.apache.xerces.parsers. XIncludeAwareParserConfiguration
- デフォルト値: なし
- 推奨値: なし
- 動的キャッシュ・サービスの調整。
動的キャッシュ・サービスを使用すると、パフォーマンスを向上させることができます。 動的キャッシュ・サービスの使用と、それがアプリケーション・サーバーのパフォーマンスに与える影響については、 パフォーマンス向上のための動的キャッシュ・サーバーの使用に関する情報を参照してください。
Web コンテナーの調整。 製品の Web コンテナーは、サーブレット、JavaServer Pages、および Web サービスに対するすべての HTTP 要求を管理します。要求は、トランスポート・チェーンから Web コンテナーへと流れます。トランスポート・チェーンは、 Web コンテナーのパフォーマンスに関する重要なチューニング・パラメーターを定義します。 製品が HTTP 要求を listen する各 TCP ポートごとにトランスポート・チェーンがあります。 例えば、デフォルトの HTTP ポート 9080 は、Web コンテナー・インバウンド・チャネル・チェーンで定義されます。 次のパラメーターを使用して、Web コンテナーを調整します。
- HTTP 要求は、サーバー・スレッドのプールによって処理されます。Web コンテナーの最小および最大スレッド・プール・サイズを、
最良のパフォーマンスを得るように構成することができます。
通常、サーバー CPU ごとのスレッドを 5 ないし 10 にすると、最高のスループットが得られます。
構成されるスレッドの数は、製品が並行して処理できる要求の数を表すわけではありません。
すべてのスレッドが使用中である場合、
要求はトランスポート・チェーンでキューに入れられます。
スレッド・プール設定を指定するには、以下のようにします。
- 「サーバー」>「サーバー・タイプ」>「WebSphere Application Server」> server_name 「Web コンテナー設定」>「Web コンテナー」>「Web コンテナー・トランスポート・チェーン」をクリックします。
- 要求を実行するための通常のインバウンド・チェーンを選択します。このチェーンは通常、WCInboundDefault と呼ばれており、ポート 9080 で listen します。
- 「TCP Inbound Channel (TCP_2)」をクリックします。
- 「関連項目」の下にある「スレッド・プール」を設定します。
- 「WebContainer」を選択します。
- 「最小サイズ」および「最大サイズ」の値を入力します。
- HTTP 1.1 プロトコルは、キープアライブ・フィーチャーを提供しており、
これにより HTTP クライアントとサーバー間の TCP 接続は、各要求の合間にオープンな状態のままでいることができるようになります。
デフォルトで、本製品は、指定された要求の数またはタイムアウト期間に達すると、指定のクライアント接続をクローズします。
接続がクローズされた後、クライアントが別の要求を発行すると、接続は再作成されます。
接続の閉止が早いと、パフォーマンスが低下する場合があります。
パーシスタント (キープアライブ) 要求の最大数の値を入力し、単一の HTTP 接続に許可される要求数を指定します。
パーシスタント・タイムアウトの値を入力し、
HTTP トランスポート・チャネルが、ソケットを各要求の合間にアイドル状態にしておく時間を秒数で指定します。
最大のパーシスタント要求数およびパーシスタント・タイムアウトの値を指定するには、次のようにします。
- 「サーバー」>「サーバー・タイプ」>「WebSphere Application Server」> server_nameをクリックします。次に、「コンテナー設定」セクションで、「Web コンテナー」>「Web コンテナー・トランスポート・チェーン」をクリックします。
- 要求を実行するための通常のインバウンド・チェーンを選択します。このチェーンは通常、WCInboundDefault と呼ばれており、ポート 9080 で listen します。
- 「HTTP Inbound Channel (HTTP_2)」をクリックします。
- 「最大のパーシスタント要求数」および「パーシスタント・タイムアウト」の値を入力します。
- HTTP 要求は、サーバー・スレッドのプールによって処理されます。Web コンテナーの最小および最大スレッド・プール・サイズを、
最良のパフォーマンスを得るように構成することができます。
通常、サーバー CPU ごとのスレッドを 5 ないし 10 にすると、最高のスループットが得られます。
構成されるスレッドの数は、製品が並行して処理できる要求の数を表すわけではありません。
すべてのスレッドが使用中である場合、
要求はトランスポート・チェーンでキューに入れられます。
スレッド・プール設定を指定するには、以下のようにします。
- EJB コンテナーの調整。 Enterprise JavaBeans (EJB)
コンテナーは、アプリケーション・サーバーを作成すると自動的に作成されます。
EJB コンテナーのデプロイ後は、以下のパラメーターを使用して、パフォーマンスを向上させる調整を行うことができます。
- 「クリーンアップ間隔」および「キャッシュ・サイズ」を設定します。詳しくは、 EJB キャッシュ設定に関するトピックを参照してください。
- CMP エンタープライズ Bean をいくつかの エンタープライズ Bean モジュールに分割します。詳しくは、 EJB モジュールのアセンブルに関するトピックを参照してください。
詳しくは、EJB メソッドの起動キューイングに関する トピックを参照してください。
- セッション管理の調整。
セッション管理のインストール済みデフォルト設定は、パフォーマンスに関して最適化されています。
- データ・ソースと関連接続プールの調整。 データ・ソースは、データベースのデータにアクセスするために使用し、
そのデータベースへの接続のプールと関連しています。
- 接続プール内の物理接続の数によってどのようにパフォーマンスが変化するかを理解するには、 接続プーリングに関するトピックを確認してください。
パフォーマンスに最も影響するデータ・ソースおよび接続プール・プロパティー については、データ・アクセス・チューニング・パラメーターに関するトピックを参照してください。
- URL 呼び出しキャッシュの調整。
各 JavaServer Page は固有の URL です。実際に使用中の固有の URL 数が 50 を超えている場合は、invocationCacheSize JVM カスタム・プロパティーで指定された値を大きくします。 このプロパティーは、URL 呼び出しキャッシュのサイズを制御します。
アプリケーション・コンポーネントが使用しているすべてのログ・ストリームをリカバリー・ログ・サービスで圧縮する頻度の変更。
トランザクション・サービス RLS_LOGSTREAM_COMPRESS_INTERVAL がログ・ストリームを使用する唯一のアプリケーション・コンポーネントである場合は、このトランザクション・サービスのカスタム・プロパティーをデフォルト値よりも大きな値に設定できます。 ログ・ストリームを使用するように設定されたコンポーネントがない場合は、このプロパティーを 0 (ゼロ) に設定して、この機能を使用不可にすることができます。
サブトピック
定義済み調整テンプレートを使用したアプリケーション・サーバーの調整
Python ベースの調整スクリプト applyPerfTuningTemplate.py をそのテンプレート・ファイルの 1 つとともに使用して、定義済みのパフォーマンス調整テンプレートをアプリケーション・サーバーまたはクラスターに適用することができます。プロパティー・ベースのテンプレート・ファイルは WAS_HOME¥scriptLibraries¥perfTuning¥V70 ディレクトリーにあります。 スクリプト・ファイルのパスは wsadmin -f <WAS_HOME>¥bin¥applyPerfTuningTemplate.py です。Web コンテナーの最適化された通信に対する Web サービス・クライアント
パフォーマンスを改善するために、同じアプリケーション・サーバー・プロセスに配置された Web サービス・クライアント・アプリケーションと Web コンテナーとの間に、最適化された通信パスがあります。 通常、ネットワーク接続を使用して Web コンテナーに送信される Web サービス・クライアントからの要求は、 最適化されたローカル・パスを使用して Web コンテナーに直接配布されます。 Web サービス・クライアント・アプリケーションと Web コンテナーが同じプロセスで稼働しているため、 ローカル・パスは使用可能です。


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