Sun GlassFish Enterprise Server 2.1 配備計画ガイド

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

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

配備するアプリケーションやサービスの種類と、クライアントからのアクセス方法。
高可用性を必要とするアプリケーションやサービス。
アプリケーションはセッション状態を持つか、または状態を持たないか。
システムでサポートする必要のある要求の容量またはスループット。
システムでサポートする必要のある並行ユーザーの数。
ユーザー要求に対する許容可能な平均応答時間。
要求の間の平均思考時間。

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

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

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

スループットの見積もり

広義では、スループットは Enterprise Server によって実行された作業の量を測定します。Enterprise Server の場合、スループットは、サーバーインスタンスあたり、1 分あたりに処理された要求の数として定義できます。また、高可用性アプリケーションでは、セッション状態データが定期的に保存されるため、HADB にもスループット要件が課せられます。HADB の場合、スループットは、1 分あたりに格納されるセッションデータの量として定義できます。これは、1 分あたりの HADB 要求の数と、1 要求あたりの平均セッションサイズの積です。

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

高可用性アプリケーションでは、データが HADB に定期的に保存されるため、追加のオーバーヘッドが発生します。このオーバーヘッドの量は、データの量、データが変更される頻度、およびデータの保存頻度によって異なります。最初の 2 つの要因は対象のアプリケーションによって異なり、さらに後者はサーバー設定によっても影響されます。

HADB のスループットは、1 分あたりの HADB 要求の数に、1 要求あたりの平均データ量を掛けた値として定義できます。HADB のスループットを向上させるには、より多くの HADB ノードと、より大きいストアサイズが必要になります。

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

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

並行ユーザーの最大数

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

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

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

思考時間

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

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

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

平均応答時間

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

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

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

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

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

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

T_response = n/r - T_think

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

n は、並行ユーザーの数です。
r は、サーバーが受信する 1 秒あたりの要求の数です。
T_think は、平均思考時間 (秒単位) です。

正確な応答時間結果を得るには、必ず式に思考時間を含めてください。

例 2–1 応答時間の計算

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

ピーク負荷時にシステムでサポートできる並行ユーザーの最大数 (n) は 5,000。
ピーク負荷時にシステムで処理できる要求の最大数 (r) は 1 秒あたり 1,000。

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

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

T_response = n/r - T_think = (5000/1000) - 3 秒= 5 - 3 秒

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

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

1 分あたりの要求数

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

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

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

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

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

r = n/(T_response + T_think)

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

次の値の場合、

n = 2,800 の並行ユーザー
T_response = 1 (1 要求あたりの平均応答時間は 1 秒)
T_think = 3 (平均思考時間は 3 秒)

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

r = 2800 / (1+3) = 700

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

HADB への負荷の見積もり

HADB への負荷を計算するには、次の要因を考慮します。

セッション持続性を設定する手順については、『Sun GlassFish Enterprise Server 2.1 高可用性 (HA) 管理ガイド』の第 7 章「高可用性 (HA) セッション持続性とフェイルオーバーの設定」を参照してください。

HTTP セッション持続性の頻度

HADB で受信される 1 分あたりの要求の数は、持続性の頻度に依存します。持続性の頻度によって、Enterprise Server が HTTP セッションデータを HADB に保存する頻度が決定されます。

持続性の頻度オプションを次に示します。

web-method (デフォルト): サーバーは、すべての HTTP 応答でセッションデータを格納します。このオプションによって、格納されたセッション情報が最新になることは保証されますが、HADB に対するトラフィックが増えます。
time-based: セッションは、指定された時間間隔で格納されます。このオプションによって、HADB に対するトラフィックは削減されますが、セッション情報が最新になることは保証されません。

次の表は、持続性の頻度オプションの長所と短所を要約しています。

表 2–1 持続性の頻度オプションの比較


持続性の頻度オプション	長所	短所
web-method	最新のセッション情報を使用できることが保証されます。	応答時間が長くなり、スループットが低下する可能性があります。
time-based	応答時間が短縮されるとともに、スループットが向上する可能性もあります。	アプリケーションサーバーインスタンスの障害が発生したあと、最新のセッション情報を使用できる保証は低くなります。

HTTP セッションサイズと範囲

1 要求あたりのセッションサイズは、セッション内に格納されているセッション情報の量に依存します。

ヒント –

全体的なパフォーマンスを向上させるには、セッション内の情報の量をできるだけ削減します。

「持続性の範囲」の設定を使用して、1 要求あたりのセッションサイズを微調整することができます。HTTP セッション持続性の範囲を、次のオプションから選択します。

session: サーバーは、セッション情報を HADB に保存するたびに、セッションオブジェクト全体を直列化して保存します。
modified-session: サーバーは、セッションが変更された場合、そのセッションのみを保存します。サーバーは変更を、Bean の setAttribute() メソッドへの呼び出しを傍受することによって検出します。このオプションでは内部オブジェクトへの直接の変更は検出されないため、このような場合は、setAttribute() を明示的に呼び出すように SFSB をコーディングしてください。
modified-attribute: サーバーは、そのセッションが最後に格納されたあとに変更 (挿入、更新、または削除) された属性のみを保存します。これには modified-session と同じ欠点がありますが、正しく適用すれば、HADB 書き込みスループットの要件が大幅に削減される可能性があります。

このオプションを使用するには、アプリケーションが次の処理を行う必要があります。

セッション状態を変更するたびに、setAttribute() または removeAttribute() を呼び出す。
属性間で相互参照しないようにする。
複数の属性間、または少なくとも読み取り専用属性と変更可能な属性間でセッション状態を分散します。

次の表は、持続性の範囲オプションの長所と短所を要約しています。

表 2–2 持続性の範囲オプションの比較


持続性の範囲オプション	長所	短所
modified-session	セッション状態を変更しない要求の応答時間が向上します。	Web メソッド (一般には、`doGet()` または `doPost()`) の実行中、アプリケーションは次のセッションメソッドを呼び出す必要があります。属性が変更された場合は、`setAttribute()` 属性が削除された場合は、`removeAttribute()`
session	アプリケーションに制約はありません。	`modified-session` および `modified-attribute` オプションに比べて、スループットや応答時間が低下する可能性があります。
modified-attribute	変更されたセッション状態の割合が低い要求のスループットや応答時間が向上します。	特定の要求に対する変更されたセッション状態の割合が 60% に近づくと、スループットや応答時間は低下します。このような場合は、属性を個別のレコードに分割するためのオーバーヘッドにより、パフォーマンスはほかのオプションの場合よりも低下します。

ステートフルセッション Bean のチェックポイント設定

SFSB セッション持続性の場合、HADB への負荷は次の要素に依存します。

チェックポイント設定が有効になっている SFSB の数。
チェックポイント設定のために選択されている SFSB メソッドと、その使用頻度。
セッションオブジェクトのサイズ。
トランザクションで使用するメソッド。

チェックポイント設定は一般に、その SFSB を含む任意のトランザクションが完了したあとに (そのトランザクションがロールバックした場合でも) 発生します。

パフォーマンスを向上させるには、チェックポイント設定に指定するメソッドのセットを小さくします。チェックポイントを設定するデータのサイズと、チェックポイント設定の頻度によって、特定のクライアント対話の応答時間で発生する追加のオーバーヘッドが決定されます。