|
|
BEA WebLogic Portal は、柔軟性に富んだフレームワークに構築したエンタープライズ クラス ポータル インフラストラクチャであり、顧客の高パフォーマンスの予測を満たすために設計されています。この製品のデプロイメントは、少数マシンによる小さい部門 アプリケーションからクラスタ コンフィグレーションで多くのマシンを構成する大きなデプロイメントまで多岐にわたります。特定のアプリケーションのアーキテクチャと物理デプロイメントはいくつかの要因に依存していますが、それについてはこのドキュメントで後ほど説明します。アプリケーションのニーズを十分に満たすために必要なソフトウェアおよびハードウェア コンフィグレーションを決定するプロセスを、キャパシティ プランニングといいます。
このドキュメントでは、WebLogic Portal 9.2 のキャパシティプランニングに必要な手順について説明し、顧客がキャパシティ プランニングのより正確な見積もりができるように測定のベースライン セットとしての役割を果たします。
キャパシティ プランニングは精密科学ではありません。アプリケーションやユーザの動作はそれぞれ異なります。このドキュメントは、キャパシティ プランニングの数値を求めるためのガイドとしてのみ利用されることを目的としています。利用の際には細心の注意を払うようにしてください。プロダクション環境にいずれかのアプリケーションをデプロイする前に、アプリケーションで綿密なパフォーマンス テスト サイクルを行う必要があります。パフォーマン ステストの詳細については、「Approaches to Performance Testing」を参照してください。
| 注意 : | このガイドで推奨されている事項はすべて、システムをプロダクション環境に移行する前に十分に検証する必要があります。上記で説明したように、このドキュメントで公開したデータはテスト済みの特定のコンフィグレーションを表します。システムがどの程度のキャパシティをサポートするかを判断する場合にさまざまな要因を考える必要があるため、プロトタイプの十分なテストを実行することなしに独自のキャパシティプランニングの数値を取得することはできません。 |
WebLogic Portal と特定のアプリケーションをサポートするために、ハードウェア コンフィグレーションにどの程度のキャパシティが必要となるかは、さまざまな要因に左右されます。アプリケーションのサポートに必要なハードウェア キャパシティは、アプリケーションとコンフィグレーションの詳細によって異なります。それぞれの要因がコンフィグレーションとアプリケーションにどう影響するのかを考える必要があります。
以下の節では、これらのいくつかの要因について説明します。これらの要因を理解し、アプリケーションの要件を検討しておくと、コンフィグレーション内のサーバのハードウェア要件を作成する際に役立ちます。
キャパシティ プランニングはパフォーマンス テスト プロセスの最後の手順です。アプリケーションをプロダクション デプロイメントに準備する前に、システムのすべてのボトルネックがなく、アプリケーションをできるだけ速く実行できるようにアプリケーションのインタラクティブ パフォーマンス テストを実行する必要があります。
アプリケーションに対してベンチマークを実行すると、測定のベースライン セットが設定され、アプリケーションに機能を追加および削除した後の影響を測定できます。
開発時にアプリケーションをプロファイルすると、後で大きな問題になる可能性のあるパフォーマンスの問題またはパフォーマンス hotspots を解決することができます。このような問題を早期に検出することで、後から修正するためのオーバーヘッドを大幅に減らします。
この内容については多くのドキュメントがありますが、BEA's dev2dev サイトの「Approaches to Performance Testing」をまず参照してください。
WebLogic Portal 9.2 に対して BEA がサポートするオペレーティング システムおよびハードウェア コンフィグレーションについては、「WebLogic Platform 9.2 でサポート対象のコンフィグレーション」ページに記載されています。
特定の WebLogic Portal アプリケーションのパフォーマンスの目標は、遅い応答時間、不十分な同時ユーザ実行、またはアプリケーションのスループットが非常に低いなどの理由で、達成できない場合もあります。このような状況で、最初にたずねる質問として次のものがあります。どのようなハードウェアを使用して Portal を実行していますか。これは、システムは適切にスケールされているかを判断する時の最も重要な要因です。BEA の内部パフォーマンス テストの時、WebLogic Portal は CPU にバインドしているため、システムのパフォーマンスは CPU のスピードと CPU の合計数に依存します。
BEA の内部パフォーマンス テストは、システム パフォーマンスと CPU の全体的なクロック スピード間の直接関係を示します。１つ以上の CPU または高スピードの CPU を追加すると、システムのキャパシティが増加されます。また、マシンのクラスタ化によって、全体的なアプリケーションのデプロイメントに 使用できる CPU 数が増加するため、WebLogic Portal のスケーラビリティが向上します。最新のプロセッサ技術も、システムの動作を決定する際の大きな要因となります。たとえば、結果のセクションでは、Sun の UltraSPARC IIIi プロセッサ上に一連のデータがあり、マシンに 4 つの CPU があっても、パフォーマンスは Intel Xeon プロセッサ上の結果と同等ではありません。
可能な限り処理速度の早い CPU および必要に応じてクラスタのサイズを増加することをお勧めします。
WebLogic Portal Server デプロイメントは、クラスタをサポートするようにコンフィグレーションされていますか。クラスタは、複数のシステム間への負荷の分散に加え、セッションの保護と状態のレプリケーションによるフェイルオーバを実現します。アプリケーションのセッションに大量のデータがあって、そのセッションがクラスタ間に複製されている限り、クラスタを使用している顧客がパフォーマンスの低下を著しく感じることはありません。
Web サーバを使用して WebLogic Server クラスタにリクエストを転送している場合は、Web サーバがボトルネックになることがあります。この問題は、付属の HttpClusterServlet とプロキシ サーバを使用している場合、またはサポート対象のいずれかのプラグインを使用している場合に発生する可能性があります。クラスタにサーバを追加しても応答時間が改善されず、Web サーバ マシンの 高速 CPU 使用率が示す場合は、Web サーバをクラスタ化するか、Web サーバを実行しているハードウェアを強化することを検討してください。Web サーバは、CPU 処理より I/O （ディスクの使用率とネットワークの使用率を含む）処理の割合を高くする必要があります。
チューニングされた アプリケーションのキャパシティ テストに基づき、WebLogic Portal は、一般に、CPU 処理が高くなっています。プロダクション環境用に購入するハードウェア数を決定する場合は、プロセッサの速度を最優先にする必要があります。
ほとんどの場合、WebLogic Server クラスタは、2 個の CPU につき 1 つの WebLogic Server インスタンスの割合でデプロイするのが最適です。ただし、すべてのキャパシティ プランニングと同じように、サーバ インスタンスの最適数および分散方法を決定する場合は、対象となるポータル アプリケーションで実際のデプロイメントを事前にテストする必要があります。
システムのパフォーマンス要件を判断する場合、アプリケーションの予想される負荷を考慮する必要があります。たとえば、一般的なバンキング アプリケーションでは、午後 9 から午前 5 までの「ピーク時間」に重いトラフィック (多数の同時セッション) となります。キャパシティを見積もる時、予期される負荷とできるだけ同じ負荷でテストを行うのが最適です。
さまざまな負荷の要因は、システムの全体的なパフォーマンスに影響を与え、これらの要因がどのようにテストされるかによって結果が異なります。第 1 の要因は、システム上のユーザの予期された「思考時間」です。思考時間は、アクティブ ユーザのリクエスト間の休止として定義されます。たとえば、ユーザは銀行口座の残高をチェックするためにクリックすると、30 秒まで再度クリックできない可能性があるので、思考時間は 30 秒になります。すべてのユーザ (「エキスパート」ユーザの思考時間は短くて、「新しい」ユーザの思考時間は長いため) の思考時間の平均値を計算してその値を使用してシステムのテストを実行する必要があります。思考時間を減少させると、システムに高い負荷がかかるので追加のハードウェア リソースが必要になります。
システムをテストする時、システムに追加するユーザ率も、システムのパフォーマンス特性に著しい影響を与える可能性があります。たとえば、すべてのユーザがシステムに同時に追加されると、「wave」効果が発生し、最初に応答時間が非常に増加しますが、ユーザが休止の状態になると向上し、次にユーザがシステムを通じて移動すると急速に増加します。ユーザを間隔をおいて追加すると、上記の状態を回避することができ、システムは一貫性のあるパフォーマンスで動作するようになります。思考時間をランダムに定義すると、「wavy」動作が減少され、より一貫性のある結果が得られます。
キャパシティ要件を決定するためにシステムをテストする時、シミュレートされたユーザは、プロダクション環境で発生する問題が正確に反映されているかを確認する必要があります。システム上、同時に発生する過度のシミュレートされた負荷に注意します。
WebLogic Portal 用の同時ユーザ セッションの最大数を決定します。処理するユーザ数が多いほど、スケーラビリティを図るために適切な CPU キャパシティと RAM が必要です。サポート対象のコンフィグレーションは最低で 1GB RAM であり、プロダクション環境における WebLogic Portal の各インスタンスに対しては 2GB をお勧めします。
次に、同時にリクエストを発行するクライアントの最大数と、各クライアントがリクエストを発行する頻度を調べます。WebLogic Portal とユーザ間の 1 秒当たりの対話数が、Portal デプロイメントで 1 秒間に処理する必要がある合計対話数になります。
また、需要の急激な増加に対応するために、特定期間内のトランザクションの最大数も考慮する必要があります。急激な増加に対応するために、システム上に十分なキャパシティがあることを確認します。システムに対して最大キャパシティの需要がある場合は、全体的なシステムのパフォーマンスとキャパシティを向上させるためにハードウェアを追加する必要があります。同時ユーザに関するキャパシティ情報については、「同時ユーザ結果」を参照してください。
WebLogic Portal は十分にチューニングされていますか。提供されているチューニング ガイドを参照して、WebLogic Server をチューニングする必要があります。
WebLogic Portal および WebLogic Server のチューニングの詳細については、以下を参照してください。
アプリケーションは適切に設計されていますか。ユーザ アプリケーションの設計が不適切だったり、最適化されていない場合、コンフィグレーションのパフォーマンスが低下する可能性があります。WebLogic Portal 用に開発されているアプリケーションの持つ機能は、オーバーヘッドを追加するため、ベンチマーク アプリケーションと同様のパフォーマンスは期待できないと考えるようにしてください。念のため、アプリケーションのこれらの機能を考慮してシステムに追加のキャパシティを追加する必要があります。
ポータルのサイズ (異なったブック、ページおよびポートレットの数を追加することによって計算されたポータルの分類に基づく) が システムのパフォーマンスとキャパシティに重要な影響を与える可能性があることに注意する必要があります。ポータルサイズが増加すると、表示しなければならないコントロール ツリーも増えるので、システムは小さいポータルほど動作しません。
メニューの構造を構築するには、ツリーを移動する必要があるので、複数レベルのメニューを使用すると、ポータル コントロール ツリー最適化のほとんどの利点が無効にされます。これは、小さいポータルの場合できますが、大きなポータルの場合は、システムのパフォーマンスとスケーラビリティに重要な影響を与えるので、デプロイメントに多数のハードウェア リソースが必要です。
システムのパフォーマンスを最適化するために、大きなポータルをいくつかの小さい Desktops に分割することをお勧めします。また、アプリケーション内のコードの最適化されていない領域を検索するには「heavy-weight」プロファイラーまたは実行時「light-weight」プロファイラーのプロファイリングをお勧めします。複数レベルのメニューは、大きなポータルに対して使用されません。
ポータルの設計に関する詳細については、次のドキュメントを参照してください。
セキュア ソケット レイヤ (Secure Sockets Layer : SSL) は、セキュアなインターネット通信を実現するための標準プロトコルです。WebLogic Server のセキュリティ サービスは、X.509 デジタル証明書とアクセス制御リスト (ACL) をサポートすることにより、参加者を認証し、ネットワーク サービスへのアクセスを管理します。たとえば、SSL を使用すると、従業員の給与が一覧された JSP ページを保護して、機密情報へのアクセスを遮断できます。
SSL には大量の計算処理が必要となります。SSL プロトコルで暗号化処理をサポートすると、その分だけ WebLogic Server で同時接続を処理できなくなります。
クライアントの合計数のうち、必要となる SSL 接続の数に注意してください。一般に、サーバは、1 つの SSL 接続を処理する能力で 3 つの非 SSL 接続を処理できます。SSL を使用すると、SSL 接続に使用される暗号化の強度に応じて、サーバのキャパシティは約 33 ~ 50% 低下します。また、SSL によって強いられるオーバーヘッドの量は、SSL に対応しているクライアントの対話数にも関係してきます。
ハードウェア アクセラレータを使用して SSL を実装するか、アプリケーションにおいて不要な SSL の場合、無効にします。
WebLogic Portal 以外に、何がマシン上で実行されていますか。WebLogic Portal を実行しているマシンでは、プレゼンテーションやビジネス ロジックより、はるかに多くの処理が実行されている場合があります。たとえば、Web サーバを実行していたり、株価情報サービスからの株式情報の供給など、リモート情報が常時供給されている可能性があります。ただし、これはお勧めしません。
WebLogic Portal マシンの処理能力が、WebLogic Portal に関係のないプロセスによってどのくらい消費されるのかを考慮してください。WebLogic Portal (または WebLogic Portal が稼動しているマシン) が、他に大量の処理を実行している場合は、他のプロセスにどの程度の処理能力を割り当てるかを判断する必要があります。
WebLogic Portal server 上の CPU の平均使用率は、ベンチマーク テストを実行する時に、そのマシンの累積統計として、85%～95% の範囲であることをお勧めします。たとえば、マシンは、複数のプロセッサがある場合は、その両方のプロセッサの平均は上記に説明した割合の範囲である必要があります。この場合、マシンはピーク キャパシティで操作できるではなく、CPU の使用率が 100% にされずに他のシステム プロセスも実行できるようになります。プロダクションの時、応答時間に近づく SLA が維持されるように、トラフィック内の急激な増加に対応するため、追加の CPU オーバーヘッドをシステムに追加する必要があります。
また、WebLogic Portal に加え、サードパーティのアプリケーション、サービスまたはプロセスをデプロイする場合、それらのアプリケーション、サービスまたはプロセスを別のハードウェア マシンにデプロイするようにお勧めします。
クラスタ化された WebLogic Portal デプロイメントに対応する場合は、ロード バランシング ソリューションを考慮する必要があります。クラスタ内のロード バランシングの場合、ノード間のユーザのセッションは均等に配布する必要があります。均等に配布されていない場合、WebLogic Portal コンフィグレーションまたはロード バランサ コンフィグレーションに問題があると示されます。
サーバのクラスタがシステムのキャパシティ要求を満たす必要がある場合は、負荷がマシン間に配布されるようにロード バランサを実装する必要があります。
すべてのサード パーティのアプリケーションおよびサービスは、別のハードウェアでオフ ロードする必要があります。
データベースはボトルネックになっていますか。追加のユーザ ストレージ要件はありますか。多くのインストール環境では、データベース サーバの方が WebLogic Portal よりかなり早くキャパシティを消費します。アプリケーションを処理するには、十分に堅牢なデータベースをプランニングする必要があります。通常、優れたアプリケーションには、アプリケーション サーバ ハードウェアの 3 ~ 4 倍強力なデータベースが要求されます。したがって、データベース サーバには個別のマシンを使用することをお勧めします。
一般に、データベースはボトルネックであるか、WebLogic Portal CPU に対して高速 CPU の使用率を保持できないかを通知することができます。これは、WebLogic Portal が、ほとんどの時間、アイドル状態でデータベースの応答を待っていることを示します。
一部のデータベース ベンダは、アプリケーション サーバ用のキャパシティ プランニング情報を提供し始めています。通常、これはアプリケーションの 3 層モデルに対応しています。アプリケーションによっては、データベースと対話しない処理にユーザ ストレージを必要とする場合があります。たとえば、セキュアなシステムでは、各ユーザのセキュリティ情報を格納するディスクとメモリが必要です。この場合は、1 人のユーザの情報を格納するのに必要なサイズを計算し、その値に予想されるユーザ数を掛けてください。
システムのデータベースがボトルネックにならないために別の方法があり、データベース レイヤにキャッシングを実装するのは一つの方法です。WebLogic Portal は、データベースにヒットしないようにさまざまなキャッシュを使用します。パフォーマンス テスト時に、データベースがボトルネックになっていることが判断された場合、データベースから一部の負荷を取り除くように WebLogic Portal キャッシュをチューニングすることが有効です。
サイズ構成と他のパフォーマンスに関する考慮事項については、WebLogic Portal の『データベース管理ガイド ： パフォーマンスの考慮事項』および『サイズ構成の考慮事項』を参照してください。
データベース キャッシュの詳細については、「WebLogic Portal のキャッシュ リファレンス」を確認してください。
帯域幅は十分ですか。需要に応じてリソースの供給を増やすことができないと、ネットワーク パフォーマンスに影響します。WebLogic Server では、クライアントからのすべての接続を処理するために十分な帯域幅を必要とします。HTTP クライアントのみを処理する場合は、静的ページを処理する Web サーバと同程度の帯域幅が必要です。
クラスタの場合、デフォルトでは、セッション情報のインメモリ レプリケーションは HTTP クライアントと同じネットワークを共有します。内部クラスタ通信の場合、物理ネットワークを異なるネットワークに変更し、外部トラフィックの場合、別のチャネルを使用するのは、標準ネットワーク トポロジーに代わる方法です。詳細については、「ネットワーク リソースのコンフィグレーション」を参照してください。WebLogic Portal フレームワークは、大量のセッション データを作成しませんが、カスタム アプリケーションは、この領域で重要なオーバーヘッドを追加することができます。また、同時ユーザが頻繁にリクエストを出すと、負荷が増加してネットワーク集中になる恐れがあります。アプリケーションとビジネス ニーズでセッション情報のレプリケーションが必要かどうかを検討してください。最後に、たくさんの同時ユーザとサーバへの頻繁なリクエストの組み合わせの見積もりを作成して、ネットワークが予期される負荷を処理することができるかを判断します。
特定のデプロイメントの帯域幅が十分かどうかを調べるには、ネットワーク オペレーティング システム ベンダから提供されているネットワーク ツールを使用します。これを測定するには、多くのフリー ツールと商用 ツールだけではなく、Windows および Solaris の組み込みアプリケーションもあります。また、ほとんどのハードウェア ロード バランシング ソリューションがネットワーク統計を提供します。ロード バランサを 1 つのみ使用すると、負荷が高い時、システムのボトルネックになる可能性があります。
ネットワーク トラフィックを最適化するために、ギガビット LAN と 1 つまたは複数のサーバ ロード バランサを実行することをお勧めします。
どの JVM が使われるか。どんなパラメーターが使われるか。アプリケーションから最もよいパフォーマンスを得るためにどのくらいヒープが必要ですか。複数のアプリケーションでは、1 つまたは異なる JVM でのパフォーマンスが良くなる可能性があります。WebLogic Portal は、BEA の JRockit と Sun の HotSpot JVM をサポートします。一般的には、BEA の JRockit JVM は、Intel プロセッサを使用した Linux OS における「ベンチマーク」テストでのパフォーマンスが良く、HotSpot は、「同時ユーザ」テストにおいてクラスタのサイズを増やすとパフォーマンスがやや上回りました。
JVM パラメータは、システムのパフォーマンスに劇的な影響を与える可能性があります。すべてのパラメータのリストと使用方法については、『BEA JRockit リファレンス マニュアル』を参照してください。
ヒープのサイズも、システムのパフォーマンスに影響を与えます。大規模なアプリケーションの場合、大規模なヒープ サイズが必要になる可能性があります。また、同時ユーザの数が大きくなると、システムのメモリ不足を回避するためにヒープサイズを増やす必要があります。
JRockit の場合、-Xgc:parallel と HotSpot の場合、-XX:MaxPermSize を使用し、最小のサイズは 128m であることをお勧めします。アプリケーションに応じて、メモリ要件はかなり高くなる可能性があります。すべての場合において、アプリケーションに対してベストなものを判断するためにさまざまな設定を行ってベンチマーク テストを実行する必要があります。
パフォーマンス テスト結果は以下の 2 つの種類があります。スループットをアクセスするためのテストとシステムがサポートされる同時ユーザの最大数を判断するためのテストです。これらのテストの違いは非常に多いため、両方のテストのデータ ポイントを比較する方法はお勧めしません。
最初のデータ セットは、「ベンチマーク結果」と呼ばれます。このデータセットのテストでは、システムのスループットのべースラインが判断され、スループットは 1 秒につき返されたページ数で測定します。これらのテストの目的は、ポータル サイズ、ポートレット タイプおよび JVM が異なるさまざまなコンフィグレーションでのシステムの最大スループットを判断することです。
2番目のデータのセットは、プロダクションのようなシステムで実行するテストに関連するので、「同時ユーザ結果」と呼ばれます。これらのテストの目的は、一定の応答時間 (通常 Service Level Agreement と呼ばれる) に発生する最大同時ユーザ数 (ポータルを通じてアクティブにクリックしている）を判断することです。
各テストでは、各ユーザが一回ログインしてからページをクリックして進み (非常に小規模のポータルを除いて 50 ページ/ブックのクリック)、最後のページに達すると最初のページが繰り返されるスクリプトを使用しました。非常に小規模のポータルのページ数は 8 ページであるため、クリックは 8 回でした。これは、テストの継続期間が完了されるまで続きました。
テスト アプリケーションは、「.portal」ファイルと「.portlet」ファイルを含む EAR としてクラスタにデプロイされます。各ユーザが登録されるように各ポータルに対してフォームベース認証が使用されました。ポータル自体のサイズとポートレット タイプはさまざまです。テストした各ポータルには、JSP、「同時ユーザ」テスト用のページ フロー、JSP、ページ フローおよび「ベンチマーク」テスト用の Struts などのポートレット タイプが 1 つ含まれ、使用したポートレットは「Hello World」タイプのポートレットのような単純なポートレットと考えられます。すべてのポータルに対してツリー最適化を有効になっていました。資格またはユーザ カスタマイズは有効になっていませんでした。すべてのテストに対して、「replicated_if_clustered」のフラグを使用してセッション レプリケーションをコンフィグレーションしていました。すべてのユーザに対してログインが必要でしたが、ログアウトしなかったため、テストの継続期間に各ユーザのセッションを保持しました。
非常に小規模のポータル (ページ当たり 8 つのポートレット) を除き、各ポータルにはページ当たり 10 ポートレットあります。
「ベンチマーク」テストは、異なる状況におけるシステムの最大スループットを示すために設計されています。ポータル内のポートレットのタイプ、ポータルのサイズと JVM を変化させます。各コンフィグレーションの目的は、最大スループットを取得するようにサーバを飽和させることです。WebLogic Portal servers では、CPU 使用率が 85 ～ 95 ％ の範囲に達成するのは、最大スループットの最適範囲です。
最大スループットを取得するために、「思考時間」に対してゼロ秒を使用しました。つまり、サーバからの応答と後続のリクエスト間の時間は 0 秒でした。このようなワークロードで、サーバは簡単に飽和し、比較的少ないユーザで短く時間で最大スループットを達成することができます。
ベンチマーク テストは、1 つの CPU につき、10 仮想ユーザ (LoadRunner での VUsers) を使用しました。ベンチマークは、HP Linux と Sun Solaris の 2 つのハードウェア コンフィグレーションで実行しました。テストされたすべての Linux マシンは、2 個の CPU を使用してコンフィグレーションされていたので、WebLogic Portal クラスタの各ノードに対して 1 個のマシンにつき 20 仮想ユーザを使用しました。テストした Sun Solaris のマシンは、4 個の CPU を使用してコンフィグレーションされていたので、1 個のマシンにつき 40 仮想ユーザを使用しました。これらのユーザを 20 分間「ランプアップ」 (システムに追加) してから、定常状態で (ユーザを追加せずに、既存のユーザがシステムにアクセスしている状態) 処理を続けたため、10 分追加しました。
| 注意 : | この調査で使用したベンチマークで得られた基準値は、WebLogic Portal を同様のベンチマークを実行した他のポータルやハードウェアと比較するためには使用しないでください。この調査では、独自のベンチマーク方式とチューニングが使用されています。 |
この節では、次のコンフィグレーションからの結果が表示されています。
HP Linux テストは、1 つのクラスタで、1 個、2 個、4 個、および 8 個の物理マシンのようなさまざまなクラスタ コンフィグレーションで行った場合、結果は異なりました。各マシンには、1 つの実行している管理サーバがあり、各物理マシン上で 1 つのポータルおよび 1 つの JVM に変化します。各サーバは、2 個の CPU があり、CPU カウントのデータが表の形式で示されます。
-Xms1536m -Xmx1536m -Xgc:parallel -XXaggressive -XXlargeObjectLimit:16k -XXtlasize:256k を設定した BEA JRockit JVM。 -server -Xms1536m -Xmx1536m -XX:MaxPermSize=128mを設定した Sun HotSpot JVM。
サーバが自動チューニングに設定されました。これは WebLogic Server 9.0 以降の新機能です。JDBC 接続プールは 5 接続で開始し 25 接続まで拡張できるように設定されました。サーバがすぐに飽和するように、これらのテストは思考時間を 0 秒として実行しました。
Sun Solaris のテストでは、1 つおよび 2 つの物理マシンで 4 個と 8 個の CPU コンフィグレーションを使用しました。各マシンは、2 つの管理対象サーバがあり、クラスタ内の合計 2 個および 4 個の管理対象サーバに対して、各物理マシン上の 2 つのポータルおよび 2 つの JVM に変化します。各サーバは、4個の CPU があり、CPU カウントのデータが表の形式で示されます。
-server -Xms1536m -Xmx1536m -XX:MaxPermSize=128m を設定した Hotspot。
サーバが自動チューニングに設定されていました。これは WebLogic Server 9.0 以降の新機能です。JDBC 接続プールで開始したサーバは、25 接続までに拡張できる 5 接続から開始するように設定しました。サーバがすぐに飽和するように、これらのテストは思考時間を 0 秒として実行しました。
一連のパフォーマンス テスト結果は、特定のハードウェア セットで何人の同時ユーザが実行できるかを測定してシステムの全部のキャパシティを決定するのに最適であるため、「キャパシティ プランニング」結果としても知られています。これらのテストは、同じ現実のユーザ ロードを設計して標準の「ベンチマーク」テストよりも正確にシステムを表現します。
顧客からのフィードバックに基づいて、最も一般的な SLA は、2 秒および 5 秒の応答時間です。目標は、WebLogic Portal がこのような SLA によるさまざまなコンフィグレーションを通じてどれだけの ユーザをサポートできるかを決定することです。実際に追加的なテストを実行しないと、サポートされたユーザ数を見積もるのは難しいことですが、SLA が高くなると、サポートされたユーザ数も多くなります。
キャパシティ プランニング テストに関して、思考時間とは、いわゆる「エキスパート ユーザ」によってアクセスされる現実のプロダクション システムと同じです。これは、システムにとってとても高いワークロードを考慮し、他の多くのコンフィギュレーションでは、エンド ユーザによるリクエスト時間が「エキスパート」とは同様ではありません。これらのテストのための思考時間が 5 秒+/-25% (3.75 と 6.25 秒の間)に無作為化されました。一方、ノンエクスポートのようなシステムでは、思考時間はすべてのユーザに対して平均的な 30 秒であるといえます。システムの思考時間はポータルの全部のキャパシティに著しい影響を与えます。思考時間は大きくすると、システム上に多くのユーザが実行できます。「ベンチマーク」コンフィグレーションでは、システムを飽和するには CPU あたり 10 ユーザだけ必要ですが、思考時間を考えることで、同じ影響を持つには、CPU あたり数百や数千のユーザもかかることが必要になります。
キャパシティ プランニング テスト用のワークロードは、上記に説明した「ベンチマーク」テストより大幅に異なっています。最低 SLA 要件を満たすために必要でなユーザ数はより多い（思考時間があるため）ため、テストの継続期間を延ばす必要があります。各コンフィグレーション用のユーザ数が 2 時間までランプアップし、各コンフィグレーションには、１分あたりの一定割合で別のユーザ数を追加しました。システム応答が向上し 短いランプアップ スケジュールで多くのユーザをサポートできるため 2 時間を選びました。多数のユーザは、60 秒以上の一定のレートで約 2 時間のマークを実行するまでシステムに追加しました。
このテストでは、テスト ポータルが一定の応答時間でサポートできる同時ユーザ数を確立しました。2 秒と 5 秒の目標応答時間を使用しました。表に記載されている同時ユーザ数は、2 秒または 5 秒での最大同時実行ユーザ数を表します。このテストでは、HP Linux コンフィグレーションを使用しました。「HP Linux ハードウェア とサーバ コンフィグレーション」を参照してください。各サーバは、2 個の CPU があり、CPU カウントのデータが表の形式で示されます。
WebLogic Portal では、WebLogic Platform のさまざまなコンポーネントを使用します。WebLogic Portal のチューニングの詳細については、次のドキュメントを参照してください。
  
|
