キャパシティ プランニング
以下の節では、サーバ ハードウェアのキャパシティの要件を決定する方法について説明します。
キャパシティ プランニングのこの段階では、サーバ上で予想されるアクティビティ レベル、予想されるユーザ数、リクエスト数、許容応答時間、および希望のハードウェア コンフィグレーションに関する情報を収集します。サーバ ハードウェアのキャパシティ プランニングでは、最大パフォーマンス要件を重視し、キャパシティの測定可能な目標を設定する必要があります。
個々のアプリケーションについては、「基準アプリケーションの処理結果の検討」を参考にして、そのアプリケーションが基準アプリケーションとどのように違うかを確認してください。たとえば、MedRec に類似したビジネス アプリケーションで HTTPS プロトコルを使用する場合、重量 MedRec アプリケーションのメトリックを調べる必要があります。「キャパシティ プランニングの要素」のすべての要素について同じプロセスを行います。
サンプル アプリケーションのいずれかを使用して算出された値は、当然、実際のアプリケーションで確認される値の大まかな近似値にすぎません。実際のプロダクション用アプリケーションとプロダクション用ハードウェアを使用したベンチマークに代わるものはありません。特に、実際のアプリケーションでは、テスト アプリケーションで確認されないわずかな競合や他の問題が明らかになる場合があります。
ハードウェア キャパシティ要件を計算するには、次の手順を行います。
ボックス数 = (必須 TPS) / (参照 TPS / 複雑度)
必要なボックスの数は、ほぼ次の数に等しくなります。
400/(205/2) = 400/102,5 = 3,90 を切り上げた整数 = 4 ボックス
システムのキャパシティをプロダクション環境に適用する前に、必ず、そのキャパシティをテストしてください。
BEA では、キャパシティ プランニングに関するいくつかのベスト プラクティスを推奨しています。
メインフレームやその他のハードウェアはどうか。これらのシステムのキャパシティ プランニング情報はどのように見つけるのか。メインフレームを個々の PC がたくさん集まったものと考えます。
異機種クライアント タイプについては何を想定すべきか。プログラムに基づく HTTP クライアントはどうか。疑問があるときには、最悪の条件を想定してください。このケースでは、すべてのクライアントが HTTP クライアントであると仮定し、それに合わせてキャパシティ プランニングの数値を算出します。
アプリケーションの処理速度を上げる方法を知りたい。 まずは、BEA Systems のマニュアル『WebLogic Server パフォーマンス チューニング ガイド』を使用して WebLogic Server をチューニングします。次に、sitraka の jProbe などのチューニング ツールを使用して、コードにボトルネックがないか調べます。このツールは、http://www.sitraka.com にあります。また、WebLogic Server のマニュアルとカスタマ サポートの FAQ をチェックして、アプリケーションのチューニングおよび設計ガイドが更新されていないかを確認してください。
必要なメモリ量を決める方法を知りたい。BEA Systems では、処理が最小限のキャパシティを上回ると予想される、WebLogic Server が動作する各マシンで少なくとも 256MB のメモリを設置することを推奨しています。非常に大きな負荷が予想される場合は、メモリを大量に増設することをお勧めします。
WebLogic Server デプロイメントは、メモリ内のセッション オブジェクトを RAM またはディスクへのスワップまでトラッキングします。すべてのセッション オブジェクトを格納するには、十分な RAM/ディスクがなければなりません。RAM には Java ヒープを介して Java からアクセスできます。
メモリ要件の詳細については、『WebLogic Server パフォーマンス チューニング ガイド』を参照してください。
「思考時間」とは、トランザクションまたはページ間の移動の間にユーザが費やす時間のことです。BEA のキャパシティ プランニング ベンチマークでは、思考時間は考慮されません。ベンチマークでは、前のリクエストが終了した時点ですぐに次のリクエストが送信されます。ただし、実際には、ユーザはたいてい少し時間をおいてからページ間を移動します。
推定思考時間と予想 TPS (1 秒当たりのトランザクション数) が得られれば、システムでサポート可能な同時ユーザ数を見積もるための一般的な計算式を使用できます。