このトピックでは、個々の WebSphere アプリケーション・タイプの調整についての情報と、それらのアプリケーションをサポートするサービスおよびコンテナーについての情報へのリンクを提供します。
アプリケーション・サービス提供環境 -- アプリケーション・サービス提供環境のチューニングを参照してください。 | WebSphere アプリケーション | WebSphere アプリケーション |
---|---|---|
サーバー
製品のサブシステムについては、製品のアーキテクチャーで説明しています。多くの場合、デプロイされるアプリケーションのタイプには依存しません。 |
サービス
|
J2EE リソース
|
WebSphere Application Server for z/OS の WebSphere によって、 アプリケーションを単一サーバーにインストールすることもできますし、 複数のサーバーに分散させることもできます。 アプリケーションの区分化には、多くの理由があります。 ただし、パフォーマンスについては、アプリケーションをすべて同じサーバーに置く方が、 区分化する場合よりも常にパフォーマンスが良くなります。複数のサーバーにアプリケーションを区分することを選択する場合、 シスプレックスの各システム上に少なくともレプリカ・サーバーがある場合は、より良いパフォーマンスが得られます。 WebSphere Application Server for z/OS ランタイムの WebSphere は、可能であれば、 呼び出しをシステムに対してローカルなものにしておこうとします。 したがって、例えば、ソケットではなく ローカル・プロセス間呼び出しを使用します。
サーバー領域の実行を、 サーバー領域ごとに 1 つのトランザクション、またはサーバー領域ごとに複数のトランザクションの分離ポリシーで行うのかを 選択することもできます。パフォーマンスの観点からすると、サーバー領域でより多くのスレッドを実行すると、 メモリーの消費は減少しますが、代わりにスレッドの競合が発生します。 この競合は、アプリケーションに依存します。競合の問題がない限り、通常は 複数のトランザクションをお勧めします。
ローカル・クライアントでは、 クライアントとその最適化された通信は同じシステム上で実行されます。これには、追加の クライアント CPU コストがいくらかかかりますが、通信コストは下がります。リモート・クライアントでは、 クライアント・コストは、ソケットの追加通信オーバーヘッドに相当します。CPU コストは、 どちらのシステムでもほとんど同等です。待ち時間は、リモート・クライアントよりローカル・クライアントの方が短く、 ローカル・クライアントの方がより応答時間が速いです。
1 つのシステム上に、複数のサーバー・コピーを定義することができます。 これらのコピーはクローンと呼ばれます。いくつかのクローンで実行すると、1 つのサーバー・コピーだけで 実行する場合に対して、パフォーマンスがわずかに改善されることが分かりました (非常に大規模な構成)。 いくつかの利点がある一方、IBM は現時点では、パフォーマンス向上だけを目的とした 制御領域の複製の作成をお勧めしません。 ただし、Single Point of Failure を回避したり、 停止しないでローリング・アップグレードを処理するためには お勧めします。