以下のホット・リストの推奨に従えば、多くのアプリケーションのパフォーマンスまたはスケーラビリティー、 あるいはその両方が改善されます。
「IBM WebSphere Application Server supported hardware, software, and APIs」Web サイトでハードウェアおよびソフトウェア要件を参照してください。
一時的エラーが原因で、イーサネット・アダプターがより低い速度へとシフトダウンすることがあります。 システムが十分なメモリーを持ち、メモリーのデュアル・インライン・メモリー・モジュール (DIMM) の数と位置が最適であることを検証してください。 いくつかのシステムでは、他の DIMM 構成よりも高いパフォーマンスを許可するメモリー DIMM 構成もあります。 使用すべきハードウェアが使用されているか確認してください。
アプリケーション設計までさかのぼって、パフォーマンス上の問題の多くを追跡することができます。 設計がパフォーマンス上の問題の原因となっているかどうかを検討します。
オペレーティング・システム構成は、パフォーマンス上重要な役割を担っています。 多くの場合、アプリケーションに対するいくつかの TCP/IP パラメーターの調整が必要です。
オペレーティング・システム構成は、パフォーマンス上重要な役割を担っています。 多くの場合、アプリケーションに対するいくつかの TCP/IP パラメーターの調整が必要です。
多くのアプリケーションで、最高のパフォーマンスのためにはより大きなヒープ・サイズを必要とします。
通常、タイプ 4 JDBC ドライバーはタイプ 2 JDBC ドライバーよりも高速で実行されます。 即時に前のリンクを使用して、データベース・ベンダー指定要件のリストを表示します。これにより、タイプ 4 JDBC ドライバーがご使用のデータベースに対してサポートされているかどうかを知ることができます。
JDBC データ・ソース構成は、パフォーマンスに重大な影響を及ぼす場合があります。例えば、接続プール・サイズおよび準備済みステートメント・キャッシュは、処理される並行要求の数およびアプリケーションの設計に基づいてサイズ変更される必要があります。
詳しくは、接続プール のトピックを参照してください。
いくつかのアプリケーションは、WebSphere Application Server トランザクション・ログへの高速度の書き込みを生成します。 トランザクション・ログを高速ディスクまたはディスク・アレイへ配置することによって、応答時間を改善できます。
多くの場合、その他のいくつかのコンポーネント、例えばデータベースでは、構成全体でより高いスループットを達成するための調整が必要です。
WebSphere Application Server for z/OS プログラミング・モデルおよびランタイムの目標の 1 つは、 アプリケーション開発者がアプリケーションの作成およびデプロイを行うために必要な作業を大幅に単純化することです。 WebSphere Application Server for z/OS は、 アプリケーション開発に関係する多くの配管タスクを、アプリケーション・プログラマーから取り除きます。 例えば、WebSphere Application Server for z/OS のアプリケーション・コードは、 コード自体は直接関係せずに、遠隔通信で、つまりローカルまたはリモートのオブジェクトを位置指定して、 メソッドを駆動します。 そのため、WebSphere Application Server for z/OS アプリケーションで、 ソケット呼び出しまたは TCP/IP プログラミングを直接使用することはありません。
実行内容と実行場所の分離は、アプリケーション・プログラマーから配管タスクを除去する 1 つの特徴です。 他の考慮事項は、いくつかのタイプの Bean のデータ呼び出しを処理する必要がないことであり、ユーザー認証 およびスレッド化を処理する必要もない可能性があります。通常、 アプリケーション・コードからタッチ・ソケット、RACF 呼び出し、スレッド化の管理への呼び出しは行いません。 アプリケーション・プログラマーからこれを取り除くと、この作業が終了しないという意味ではありません。 むしろ、DBA、ネットワーク管理者、 セキュリティー管理者、およびパフォーマンス分析者の作業が増える可能性があることを意味します。
最初の 3 つは、この項目の別のセクションで取り扱い、4 つ目については簡単に触れます。 アプリケーションのチューニングについて詳しくは、アプリケーション・クライアントの使用 を参照してください。
WebSphere のパフォーマンスを最適化するための z/OS サブシステムのチューニングでは、以下のステップを行います。
最初に、WebSphere for z/OS 構成を検討します。簡単な方法として、SDSF においてアプリケーション制御領域とサーバー領域を調べます。各サーバーが開始すると、ランタイムは現行の構成データをジョブ・ログに出力します。
WebSphere トレースは、問題の検出および診断において非常に役立ちます。 トレース・オプションを適切に設定することにより、重大なパフォーマンス・オーバーヘッドなしで、 問題を検出するために必要な情報を取り込むことができます。
WebSphere for z/OS トレース・オプションを検査し、ras_trace_defaultTracingLevel が 0 または 1 であること、ras_trace_basic および ras_trace_detail が設定されていないことを確認します。
ras_trace_defaultTracingLevel=3 を指定した sysprint でトレースしている場合、 ほぼ 100% のスループット低下が示される可能性があります。 しかし、CTRACE でトレースすると、 スループットの低下が 15% で済む場合があります。
これにより、 512KB のストレージがトレース・バッファー用に取得され (許容される最小値)、 メモリー所要量が削減されます。
com.ibm.ejs.*=all=disable com.ibm.ws390.orb=all=disableどちらの行も、=disable に設定されていることを確認するか、 または、この 2 行を完全に削除します。
次に構成で検討するものは、ご使用のプログラム・コードがある場所についてです。 IBM は、妥当な限り多く、LPA に WebSphere for z/OS コードと、リンク・リストの残りを インストールすることをお勧めします。 これによって、パフォーマンスに悪影響を及ぼす不必要な STEPLIB を除去します。 STEPLIB を使用する必要がある場合、コントローラーとサーバント proc の STEPLIB DD が 不必要なライブラリーを指していないかを確認します。 USS ファイル共用システムのチューニング考慮事項については、z/OS 用の UNIX システム・サービス (USS) チューニング・ヒント を参照してください。
LPA にほとんどのランタイムを置かないことを選択する場合、ご使用の主記憶装置が、ロードの増加に伴い、 負荷が高くなることがわかります。最小で、WebSphere for z/OS は 3 つのアドレス・スペースを開始し、 共用されていないコードは 1 つではなく 3 つのコピーをロードします。 ロードが増加するにつれて、 より多くのサーバントが開始し、主記憶装置への負荷を増大させます。
PATH ステートメントを検討し、必要なプログラムのみが PATH に入るように して、頻繁に参照されるプログラムが前から順番に PATH に配置されるようにします。