[z/OS]

最適化されたローカル・アダプターのパフォーマンスの考慮事項

WebSphere® Application Server for z/OS® の最適化されたローカル・アダプターの API を使用する場合、パフォーマンスに関して考慮する必要があるいくつかの領域があります。

最適化されたローカル・アダプター API は、外部アドレス・スペースと WebSphere Application Server for z/OS 上のアプリケーション間の呼び出しに対して最適なパフォーマンスを提供するように設計されており、これらの環境にあるアプリケーション間の詳細な対話を実現する新しい種類のアプリケーション・パターンを確立することが期待されています。以下の情報は、最適化されたローカル・アダプターとパフォーマンスに関して注意が必要な問題について説明しています。 以下の内容は、最適化されたローカル・アダプターを使用して最適なパフォーマンスを実現するための構成オプションについて理解することを目的に構成されています。 同一システム上の WebSphere Application Server と外部アドレス・スペースとの間の同期呼び出しに関して、最適化されたローカル・アダプターを他のテクノロジー (SOAP over HTTP など) と比較した場合のベンチマーク結果については、ここでは取り上げていません。ベンチマーク結果については、WebSphere Application Server for z/OS の『Performance Report』を参照してください。

登録 API 呼び出しの最小接続数および最大接続数の値の選択

登録 API 呼び出しの最小接続数パラメーターに大きすぎる値を選択しないようにすることをお勧めします。選択した値が大きすぎると、パフォーマンスが低下する可能性があります。 その結果、登録 API 呼び出し中に、各接続を確立し、確立した接続を最適化されたローカル・アダプターの接続プールに追加するために、外部アドレス・スペースから WebSphere Application Server 制御領域への呼び出しが行われます。サーバーとのこれらの接続が確立された場合、その接続は、登録抹消 API 呼び出しを受け取るまで、つまり、WOLA が接続をサーバーから切断し、その接続を使用可能な接続プールから削除するまで維持されます。 最小値を大きく設定しすぎると、消費されるメモリーが多くなり、登録 API および登録抹消 API にパス長さのコストが追加されます。 ニーズに合った最適な最小接続数の値を選択してください。数百の同時スレッドが 1 つの登録を共有する可能性があると予想される場合、接続のコストを登録時に負担しておくことに意味があります。1 つの登録を共有する同時スレッド数が少ないと予想される場合は、最小接続数に小さい値を設定することをお勧めします。

登録 API の最大接続数パラメーターによって、1 つの登録の、最適化されたローカル・アダプターの接続プール内の接続数に上限が設けられます。 この登録の存続中はこの上限を拡張できません。 同時の接続取得要求の数がこの値を超えると、呼び出しスレッドは、接続取得、起動、任意要求受信、またはホスト・サービスの API の待機時間パラメーターで設定されている秒数、接続が使用可能になるのを待機します。 この時間が期限切れになると、待機時間が期限切れになる前に要求に対して接続ハンドルを取得できないことを示す戻りコードと理由コードが戻されます。1 つの登録に対して設定できる接続プールの最大サイズは決まっています。 この値は、セル全体の環境変数である WAS_DAEMON_ONLY_adapter_max_conn によって導出されます。 この変数の出荷時のデフォルトは 100 です。この値は、管理コンソールを使用して変更できます。設定を変更した後はデーモンを再始動する必要があります。

最小接続数および最大接続数の設定が最適化されたローカル・アダプターの CICS リンク・サーバーに与える影響

顧客情報管理システム (CICS®) 管理下でリンク・サーバー・タスクを開始する (BBOC START_SRVR を使用) ときに、最小接続数 (MNC) パラメーターと最大接続数 (MXC) パラメーターを渡さなかった場合、MNC 登録設定はデフォルトの 1 になり、MXC はデフォルトの 10 になります。 つまり、開始するリンク・サーバー・タスク (BBO$ タスク) によって同時に開始および実行できるリンク呼び出しタスク (BBO# タスク) の数は 10 です。 これは、CICS ターゲット・プログラムを実行および開始できる WebSphere Application Server からの同時スレッドの数となります。 MXC リンク・サーバー・パラメーターの設定値には、このリンク・サーバーのインスタンスの下で開始されることが予期される標準的な ターゲット CICS プログラムの予想所要時間が反映されている必要があります。ターゲット CICS プログラムのほとんどが長期間実行される場合は、MXC 値を大きくし、WebSphere Application Server から CICS に要求が効率よく流れ続けるようにする方が適切です。ターゲット・プログラムの実行時間が短い場合は、MXC 設定値を小さくした方が効率的です。

適切な MXC 設定値を決定するには、特定の登録名でリンク・サーバーと通信している WebSphere Application Server サーバント領域の数も考慮する必要があります。 存在するサーバント領域が 1 つのみであり、そのサーバント領域が、ISOLATE に設定されたスレッド・オプションで実行されている場合、そのサーバント内の CICS に送信することができるのは 1 度に 1 つのスレッドのみです。そのため、ボトルネックが発生しないように、MXC 値をサーバント数に 1 を乗算した数に設定します。LONGWAIT に設定されたスレッドで実行されている場合、予期される要求数および呼び出される CICS プログラムのタイプ (実行時間が長い、または実行時間が短い) に応じて、1 サーバントあたり最大 40 のスレッドをアクティブにすることができます。このような場合、サーバント全体での、特定の登録名に対して実行されているリンク・サーバーへの予想される同時要求数に基づいて、MXC を設定する必要があります。最適な MXC 設定値を決定するには、数回の試験が必要となる場合があります。 小さい数値から開始し、徐々に値を大きくしてスループットが最適と判断される数値に決定します。

共有 64 ビット・メモリー

最適化されたローカル・アダプターをサポートするには、WebSphere Application Server for z/OS サーバーが 64 ビット・モードで実行されている必要があります。WAS_DAEMON_ONLY_enable_adapter 値を true または 1 に設定してデーモン・グループを初めて始動すると、WebSphere Application Server によって、64 ビットの 2 GB 境界より上のストレージに共有メモリー・バッファーが割り振られ、初期化されます。この領域のデフォルトのサイズは 32 MB です。 ここに、最適化されたローカル・アダプターの共有制御構造すべてが存在します。 この領域にメッセージ・データがキャッシュされることはありません。 メッセージ・データおよびコンテキスト・データは、サーバー・アドレス・スペースにメッセージ・データをステージングする、WebSphere Application Server for z/OS のローカル通信アドレス・スペース間テクノロジーを使用して、外部アドレス・スペースと WebSphere Application Server サーバント領域の間で受け渡されます。大規模なメッセージの場合、これは 64 ビットの 2 GB 境界より上のストレージ内にあります。現在、WebSphere Application Server のローカル通信は最大 2 GB のメッセージ・サイズをサポートし、初期の最適化されたローカル・アダプター・サポートでは、これは単一メッセージについてサポートされる最大サイズです。

アプリケーションに動作のエラーが発生して登録 API を呼び出し続け、登録抹消の呼び出しおよび終了 (これらの呼び出しが自動的にクリーンアップされる) を実行することなくループすると、デーモン・グループ用の最適化されたローカル・アダプターの共有メモリー・バッファーがオーバーフローする可能性があります。 この状態が発生すると、API 呼び出しはメモリー不足の理由コードとともに戻されます。この状況を診断するには、影響を受けたデーモン・グループのいずれかの WebSphere Application Server サーバーで次のコマンドを発行します。
F <server_name>,DISPLAY,ADAPTER,REGISTRATIONS 	 	
ディスプレイの出力から、どのジョブが登録を解放せずに消費しているかを判断し、そのジョブを再始動することによって問題を修正できます。

分析後、デフォルト値の 32 MB がデーモン・グループのニーズを満たすのには小さすぎると判断した場合は、セル全体の環境変数である WAS_DAEMON_ONLY_adapter_max_shrmem を使用してこの値を変更できます。 ただし、この値の変更は十分に検討してから行う必要があります。 値を変更すると、最適化されたローカル・アダプターの共有の 2 GB 境界より上のメモリー・バッファーを再作成することが必要となり、再作成はシステムの IPL によってのみ行うことができます。

必要なメモリー容量をおおまかに見積もることができます。 クライアント登録ごとに 392 バイトの共有メモリーが消費されるのに加えて、接続ごとに 112 バイトの共有メモリーが消費されます。 最大接続数 100 の登録では、約 12 KB の共有メモリーが消費されます。 接続が使用可能になるまで待機する必要がある (すべての接続が使用中) クライアント・スレッドごとに、追加で 80 バイトが消費されます。 登録によってホストされているサービスごとに、さらに 336 バイトが消費されます。

例えば、デーモン・グループに 200 個の登録があるとします。 各登録に 200 個の接続が含まれており、1 度に最大で 1,000 個のスレッドが接続を待機します。 この構成で消費される合計メモリーは約 20 MB です。 この場合、約 38,000 個のサービスを同時にホストするか、登録ごとに 190 個の同時サービスをホストするのに十分な共有メモリーが残ります。
200 個の登録 x 392 バイト = 78,400 バイト
200 個の登録 x 200 個の接続 x 112 バイト = 4,480,000 バイト
200 個の登録 x 1,000 個のウェイター x 80 バイト = + 16,000,000 バイト
-------------------------------- 									
20,558,400 バイト


33,554,432 バイト - 20,558,400 バイト = 12,996,032 バイトの残り
/	     サービスごとに 336 バイト
---------------------------------- 								        
38,678 個のサービス
共有メモリーのサイズを増減させる場合は、2 GB 境界より上の共有メモリーが複数の 1 MB セクションに割り振られることに注意してください。 WebSphere Application Server によって、ユーザーが指定した値が MB 単位に切り上げられます。

WebSphere Application Server からの同時アウトバウンド呼び出しの最大数の制御

最適化されたローカル・アダプターでサポートされる単一の登録について、WebSphere Application Server からの同時アウトバウンド呼び出しの最大数を制御するデーモン全体のデフォルト設定値があります。これを制御する変数は WAS_DAEMON_ONLY_adapter_max_serv です。デフォルト値は 100 です。つまり、単一の登録で実行される各種ターゲット・サービス (同時ホスト・サービス、任意要求受信、または特定要求受信の API 呼び出し) の数は 100 を超えてはなりません。 この値を変更した場合は、デーモンを再始動する必要があります。

デフォルト値の 100 の場合、この目的で 3 つの API のいずれかを使用してスレッドを特定の登録名に対する 101 個目のサーバーとしてセットアップしようとすると、adapter_max_serv に達したことを示すゼロ以外の戻りコードと理由コードが戻されます。WebSphere Application Server 内のアプリケーションがこのサービスを検索し、このサービスがすぐに使用できない場合、アプリケーションはデフォルト値である 30 秒待機した後、要求されたサービスを待機中にタイムアウトが発生したことを示す例外を受け取ります。WebSphere Application Server サーバントのログには、これは C9C24C15 マイナー・コードとして記録されます。このタイムアウトのデフォルト値である 30 秒は、Java™ EE Connector Architecture (JCA) ConnectionSpecImpl に対して setConnectionWaitTimeout() メソッドを使用することによって、アプリケーションで変更できます。

最適化されたローカル・アダプター CICS リンク・サーバーのパフォーマンスの考慮事項

CICS リンク・サーバーに対する最適化されたローカル・アダプターのサポートを使用して、WebSphere Application Server for z/OS で実行されているアプリケーションから既存の CICS アプリケーション・プログラムを呼び出すための単純な方法を提供することができます。BBOC トランザクションまたは CICS PLTPI プログラム BBOACPL2 を使用してリンク・サーバーを始動すると、最適化されたローカル・アダプターのリンク・サーバー・タスク (BBO$) が開始され、WebSphere Application Server からのプログラム・リンク要求を受信します。次にプログラム・リンク・タスク (BBO#) が開始され、開始されたこのタスクがターゲット・プログラムに対して EXEC CICS LINK を発行し、応答を受信して、受信した応答を WebSphere Application Server の呼び出し元に返信します。このサポートには、WebSphere Application Server アプリケーションのスレッド・レベル ID をターゲット CICS タスクに伝搬および表明することが含まれます。この ID の伝搬とアサーションは、BBOC START_SRVR コマンドで SEC=Y パラメーターを使用して要求されます。

SEC=N を指定してリンク・サーバーを実行し、リンク・サーバーを開始したユーザー ID の識別情報を使用すると、パフォーマンスが向上しますが、組織のセキュリティーおよび監査の要件に合わない可能性があります。

SEC=N を指定してリンク・サーバーを実行できると判断した場合は、REU=Y BBOC START_SRVR パラメーターも指定して実行すると、最適なパフォーマンスを達成できます。REU=Y を指定すると、リンク・サーバーは、プログラム起動要求の間でプログラム・リンク呼び出しタスク (BBO# トランザクション) を再利用します。
重要: この構成でリンク・サーバーを実行すると、最適化されたローカル・アダプター JCA では、個々の要求に別々の LINK トランザクション ID を渡すことができなくなり、これに対する要求の結果、ResourceException がアプリケーションにスローされます。 また、REU=Y および SEC=Y を選択しようとすると、リンク・サーバーは、伝搬および表明された ID を使用して、要求ごとに新しいプログラム・リンク・タスクを開始する必要があるため、再利用オプションは強制的に「いいえ」になります。

REU=Y オプションを指定して実行すると、プログラム・リンク・タスク (BBO#) は、いったん開始された後、登録に対して BBOC STOP_SRVR または BBOC UNREGISTER が入力されるまで、アクティブなままになります。 BBOC START_SRVR に大きい MXC 値を指定して実行しており、同時に多数の要求を受信する場合は、BBO# タスクの数が多くなる可能性があります。この場合、それらのタスクはリンク・サーバーが停止されるまで終了しません。 これは、REU=Y を使用するかどうか、および適切な MXC 値を決定する場合に考慮すべきもう 1 つの問題です。

WebSphere Application Server から CICS でのアプリケーションへの呼び出しのパフォーマンスを最大限に高めることが目的の場合は、ホスト・サービス (BBOA1SRV)、任意要求受信 (BBOA1RCA)、または特定要求受信 (BBOA1RCS) の API をアプリケーション・プログラムに直接コーディングすることを検討してください。その場合、リンク・サーバーが提供するような ID 伝搬のための組み込みサポートはありませんが、ID 伝搬が不要でありパフォーマンスの優先度が十分に高いときは、API を直接使用することが最適なオプションである可能性があります。

JCA の考慮事項

最適化されたローカル・アダプターの JCA リソース・アダプターを使用する場合は、ConnectionFactory オブジェクトから取得される接続ごとに、追加のオーバーヘッドがあることに注意してください。 アプリケーションが同じアプリケーション・メソッド内で外部アドレス・スペースまたは CICS への複数の呼び出しを行う必要がある場合は、各対話に同じ接続を使用する方が、対話ごとに別々の接続を取得するよりもパフォーマンスが向上します。さらに、同じアプリケーション・メソッド内で 1 つの JCA 対話オブジェクトを繰り返し使用できます。

最適化されたローカル・アダプター用の JCA ConnectionFactory を作成する場合は、その ConnectionFactory 用の JCA 接続プールの最小サイズおよび最大サイズを変更できます。 この接続プールは、論理接続を表します。論理接続は、対話中に物理接続 (ユーザーが BBOA1REG 登録呼び出しで指定したもの) にバインドされます。 最適なパフォーマンスを得るには、JCA 接続プールのサイズは、BBOA1REG 中に設定された物理接続プールと同じサイズにする必要があります。 JCA 接続プールに設定されているサイズが小さすぎる場合、アプリケーションは、使用可能な物理接続があっても JCA 接続オブジェクトを待機する必要があります。 物理接続プールがすべてのサーバント領域によって共有されており、複数のサーバント領域がある場合は、各サーバント領域の JCA 接続プールのサイズを小さくすることによって、すべてのサーバント領域全体の JCA 接続の合計数を、物理接続プールのサイズに合った数に維持できます。


トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cdat_perfconsid
ファイル名:cdat_perfconsid.html