test

Sun GlassFish Communications Server 1.5 配備計画ガイド

パフォーマンス目標の確立

高パフォーマンスのもっとも単純な意味は、スループットを最大化し、応答時間を短縮することです。これらの基本的な目標を超えて特定の目標を確立するには、次の内容を決定します。

これらのメトリックスの一部は、リモートブラウザエミュレータ (RBE) ツールか、または予測されるアプリケーションアクティビティーのシミュレーションを行う Web サイトのパフォーマンスおよびベンチマークソフトウェアを使用して計算できます。一般に、RBE やベンチマーク製品は並行 HTTP 要求を生成し、次に 1 分あたりの特定数の要求に対する応答時間を報告します。これらの数値を使用することによって、サーバーアクティビティーを計算できます。

この章で説明されている計算の結果は絶対ではありません。Application Server や独自のアプリケーションのパフォーマンスを微調整するときに照合するための参照点として扱ってください。

この節では、次の項目について説明します。

スループットの見積もり

広義では、スループットは Communications Server によって実行された作業の量を測定します。Communications Server の場合、スループットは、サーバーインスタンスあたり、1 分あたりに処理された要求の数として定義できます。

次の節で説明するように、Communications Server のスループットは、ユーザー要求の性質やサイズ、ユーザーの数、Communications Server インスタンスやバックエンドデータベースのパフォーマンスを含む、多くの要因から成る関数です。シミュレートされた作業負荷のベンチマークによって、1 台のマシンでのスループットを見積もることができます。

Application Server インスタンスへの負荷の見積もり

Communications Server インスタンスへの負荷を見積もるには、次の要因を考慮してください。

並行ユーザーの最大数

ユーザーは、Web ブラウザや Java プログラムなどのクライアントを介してアプリケーションと対話します。ユーザーのアクションに基づいて、クライアントは Communications Server に要求を定期的に送信します。ユーザーは、そのユーザーのセッションが期限切れでなく、終了されてもいないかぎり、アクティブと見なされます。並行ユーザーの数を見積もる場合は、すべてのアクティブユーザーを含めてください。

最初は、ユーザーの数が増えると、それに対応してスループットが増加します。ただし、並行要求の数が増えるにつれてサーバーパフォーマンスが飽和し始めるため、スループットは低下し始めます。

並行ユーザーを追加した場合に 1 分あたりに処理できる要求の数が減る点を特定します。この点は、最適なパフォーマンスに達しており、それを超えるとスループットが低下し始める時点を示します。一般には、システムをできるだけ最適なスループットで動作させるようにしてください。追加の負荷を処理し、スループットを向上させるには、処理能力の追加が必要になる場合があります。

思考時間

ユーザーが要求を連続して送信することはありません。ユーザーが要求を送信すると、サーバーがその要求を受信し、処理したあと、結果を返します。ユーザーはその時点で、新しい要求を送信する前に一定の時間を費やします。ある要求から次の要求までの時間を、思考時間と呼びます。

思考時間は、ユーザーの種類に依存します。たとえば、Web サービスの場合のようなマシン同士の対話では一般に、思考時間は人間同士の対話より短くなります。思考時間を見積もるために、マシンと人間の対話の混在を考慮することが必要な場合があります。

平均思考時間の特定は重要です。この所要時間を使用すると、1 分あたりに完了する必要のある要求の数や、システムでサポートできる並行ユーザーの数を計算できます。

平均応答時間

応答時間とは、Communications Server が、要求の結果をユーザーに返すために費やす時間のことを指します。応答時間は、ネットワーク帯域幅、ユーザーの数、送信される要求の数とタイプ、平均思考時間などの要因によって影響されます。

ここでは、応答時間は平均の応答時間を指します。要求のタイプごとに、独自の最小応答時間があります。ただし、システム性能を評価する場合は、すべての要求の平均応答時間に基づいて分析します。

応答時間が速ければ速いほど、1 分あたりに処理される要求が増えます。ただし、システム上のユーザーの数が増えるにつれ、1 分あたりの要求の数が低下するにもかかわらず応答時間も増え始めます。

この図のようなシステム性能のグラフは、特定の点を過ぎると、1 分あたりの要求数が応答時間に反比例することを示しています。点線の矢印で表されているように、1 分あたりの要求数の低下が激しければ激しいほど、応答時間の増加も急になります。

この図の場合、ピーク負荷の点は、1 分あたりの要求数が低下し始める時点になります。この点より前は、数式にピークの数値が使用されていないため、応答時間の計算は必ずしも正確ではありません。この点よりあとは、1 分あたりの要求数と応答時間の間に反比例の関係があるため、管理者は、ユーザーの最大数と 1 分あたりの要求数を使用して応答時間をより正確に計算できます。

ピーク負荷時の応答時間 (秒単位) である Tresponse を特定するには、次の数式を使用します。

Tresponse = n/r - Tthink

次に、各引数について説明します。

例 2–1 応答時間の計算

次の条件が存在する場合、

平均思考時間 (Tthink) は 1 要求あたり 3 秒。

応答時間の計算は次のようになります。

Tresponse = n/r - Tthink = (5000/1000) - 3 秒= 5 - 3 秒

したがって、応答時間は 2 秒です。

システムの (特に、ピーク負荷時の) 応答時間を計算したら、それを、アプリケーションで許容可能な応答時間と比較します。応答時間は、スループットとともに、Application Server のパフォーマンスにとって重要な主要要因の 1 つです。

1 分あたりの要求数

任意の時点での並行ユーザーの数、その要求の応答時間、およびユーザーの平均思考時間がわかっている場合は、1 分あたりの要求数を計算できます。一般には、システム上に存在する並行ユーザーの数の見積もりから始めます。

たとえば、Web サイトパフォーマンスソフトウェアの実行後、管理者が、オンラインバンキング Web サイトで要求を送信する並行ユーザーの平均数を 3000 と結論付けます。この数は、オンラインバンクの会員登録を申し込んだユーザーの数、バンキングトランザクション動作、要求を送信する曜日または日時などに基づきます。

したがって、これらの情報がわかれば、この節で説明した 1 分あたりの要求数の数式を使用して、このユーザーベースに対してシステムが処理できる 1 分あたりの要求数を計算できます。ピーク負荷時には 1 分あたりの要求数と応答時間が反比例関係になるため、より優れた応答時間を得るためのトレードオフとして 1 分あたりの要求数を減らすことが許容可能かどうか、あるいは、1 分あたりの要求数を増やすためのトレードオフとして応答時間を遅くすることが許容可能かどうかを判断してください。

システム性能を微調整するための開始点として許容可能な 1 分あたりの要求数と応答時間のしきい値で試してください。そのあと、システムのどの領域に調整が必要かを判断してください。

前の節の式で r を求めると、次のようになります。

r = n/(Tresponse + Tthink)

例 2–2 1 秒あたりの要求数の計算

次の値の場合、

1 秒あたりの要求の数の計算は次のようになります。

r = 2800 / (1+3) = 700

したがって、1 秒あたりの要求の数は 700、1 分あたりの要求の数は 42000 です。