WebSphere Application Server キューの構成に関する方法論があります。 データベース・サーバーを別のマシン上に移動したり、より強力なリソース (より多くのメモリーを備えた高速な CPU セットなど) を供給したりすることによって、システムのダイナミックスは劇的に変化する可能性があります。
一般に、要求は WebSphere Application Server 内ではなく、
Web サーバーの手前のネットワーク内で待機します。
この構成では、キューイング・ネットワークに入る処理の準備のできた要求だけがサポートされます。
最も遠い上流の (すなわちクライアントに最も近い) キューを少し大きめに指定し、
下流側の (すなわちクライアントから最も遠い) キューほど小さくなるように指定します。
キューイング・ネットワーク内にあるキューは、処理が下流へと流れるにつれて徐々に小さくなっていきます。
この Web サーバーは 75 個の同時クライアントを処理するように設定されているので
、Web サーバーに 200 個のクライアント要求が到着した場合は、125 個の要求がネットワー
ク内にキューイングされたままになります。その 75 個の要求が Web サーバーから Web コンテナーへと受け渡されると、25 個の要求が Web サーバー内にキューイングされたままとなり、残りの 50 個は Web コンテナーによって処理されます。25 個のユーザー要求が最終宛先であ
るデータベース・サーバーに到達するまで、この処理はデータ・ソース全体を通して進行
します。各ポイント・アップストリームにはコンポーネントに入ろうと待機中の
作業があるので、このシステム内のどのコンポーネントも作業の到着を待つ必要はあり
ません。
要求の大部分は、WebSphere Application Server の外部のネットワーク内で
待機しています。このタイプの構成では、過負荷となるコンポーネントがないため、安定度が
向上します。
意味のあるすべてのコード・パスを使用するか、実稼働アプリケーションを使
用することによって、実稼働アプリケーションの全力を表すようなテスト・ケースを使
用できます。システム能力を完全に出し切ったとき、すなわち飽和点に達したときを判別するために、一連の実験を実行します。これらのテストは、アプリケーションからほとんどのボトルネックが除去された後で実行してください。
これらのテストの目的は、CPU を活用して 100% に近い使用率にすることです。
システムの並行性が最大である場合は、ラージ・キューを使用した最初の基本的な実験を開始します。例えば、キューイング・ネットワーク内の各サーバー、つまり Web サーバー、Web
コンテナー、およびデータ・ソースにおいてキュー・サイズを 100 にして、最初の実験を開始し
ます。スループット・カーブを作図する一連の実験を開始し、1 つの実験が終わるたびに同時ユーザーの負荷を増やします。
例えば、1 ユーザー、2 ユーザー、5、10、25、50、100、150 および 200 ユーザーで、
実験を行います。
1 回ごとに、1 秒ごとのスループット要求数と要求ごとの応答時間 (秒) を記録します。
基本的な実験から得られるカーブの結果は、
次に示すような一般的なスループット・カーブと似ています。
WebSphere Application Server のスループットは、システム全体に存在する同時要求の数についての関数です。セクション A の軽負荷ゾーンは、同時ユーザー要求の数が増えるにつれて、 スループットが要求の数と共にほぼ直線的に増えることを示しています。負荷が軽いときには、 同時要求が WebSphere Application Server のシステム・キュー内で輻輳 (ふくそう) 状態になることはほとんどありません。 ある点から輻輳状態が徐々に増え始め、WebSphere Application Server システム 内のボトルネックによって決まる、最大スループット値を表す飽和点に達するまでは 、スループットはずっと小さな割合で向上していきます。 最も管理しやすいタイプのボトルネックが発生するのは、 WebSphere Application Server マシンの CPU が完全に使用されたときです。 これは、追加の CPU またはより強力な CPU がボトルネックを修正するためです。
重負荷ゾーン、つまりセクション B では、同時クライアントの負荷は増えますが 、スループットは比較的一定のままです。ただし、応答時間はユーザー負荷に比例して長くなります。 つまり、重負荷ゾーンでユーザー負荷を倍にすると、応答時間も倍になります。セクション C (バックル・ゾーン) として表 されるある点に達すると、システム・コンポーネントの 1 つが使用し尽くされます。この点から、スループットの低下が始まります。 例えば、Web サーバーでのネットワーク接続がネットワーク・アダプターの制限を 使い切ってしまったり、オペレーティング・システムがファイルを処理するための限 度を超えたりすると、システムはバックル・ゾーンに入ります。
システム CPU の使用率が 100% 近くなり、飽和点に達した場合は、次のステ ップに進むことができます。システムの使用率が 100% 近くなる前に CPU の飽和が生じる場合は、 アプリケーションが別のボトルネックを悪化させている可能性があります。例えば、 アプリケーションによって、Java コードでのガーベッジ・コレクションのボトルネックを過剰に発生させるような Java オブジェクトが作成されている場合があります。
アプリケーションのボトルネックを管理する方法には、ボトルネッ クを除去する方法と、ボトルネックのクローンを作成する方法の 2 つがあります。ボトルネックの最良の管理方法は、 ボトルネックを除去することです。Rational Application Developer、Performance Trace Data Visualizer (PTDV)、Borland's Optimizeit、 JProbe や Jinsight などの Java ベースのアプリケーション・プロファイラーを使用して全体的なオブジェクト使用率を調べることができます。
スループットの飽和点における同時ユーザー数は、そのアプリケーションの最大並行性を 表します。例えば、ユーザー数 50 のときにアプリケーションが WebSphere Application Server を飽和状態にするならば、ユーザー数を 48 にするのがスループットと応答時間の最良の組み合わせでしょう。この値は、最大アプリケーション並行性の値と呼ばれます。最大アプリケーション並行性は、 WebSphere Application Server システム・キューを調整するための推奨値になります。ユーザーのほとんど はネットワーク内で待機していることが望ましいので、クライアントから下流へとに移動す るにつれ、キューのサイズは小さくするべきであることを覚えておいてください。 例えば、最大アプリケーション並行性の値が 48 である場合、システム・キューの 値は、Web サーバー 75、Web コンテナー 50、データ・ソース 45 から始めます。 上記の値を微調整して最適な設定値を見つけ、追加の実験を続けてください。
同時ユーザー数を決定するためには、Tivoli Performance Viewer で、Servlet Engine Thread Pool および Concurrently Active Threads メトリックを表示します。
通常は、わずかな要求だけが 1 つのキューを通過して、次のダウンスト リームに入ります。 多数の静的ページがあるサイトでは、要求の多くが Web サーバー・サイドで処理され、 Web コンテナーには渡されません。 このような環境では、Web サーバーのキューが Web コンテナーのキューよりもかな り大きい場合があります。前の例では、Web サーバー・キューを最大アプリケーション並行性に近い値ではなく、75 に設定しました。各 コンポーネントの実行時間が異なる場合にも、 同様の調整を行うことができます。
例えば、実行時間の 90% が複雑なサーブレット に費やされ、10% のみで短時間の JDBC 照会を行うようなアプリケーション の場合、どの時点においてもデータベース接続を使用しているサーブレット は平均 10% なので、データベース接続キューを Web コンテナーのキューよりかなり小さくすることができます。逆に、サーブレット実行時間の大半がデータベースに対する複雑な照会に費やされている場合は、Web コンテナーとデータ・ソースの両方でキューの値を増やすことを検討します。WebSphere Application Server と データベース・サーバーの両方について、常に CPU とメモリーの使用率をモニターし、CPU やメモリーが 飽和状態になっていないことを確認してください。