|
|
BEA WebLogic Portal は、最高のパフォーマンスの実現という顧客の期待に応えることを目的として設計された柔軟性のあるフレームワークを基盤とする、エンタープライズ クラスのポータル インフラストラクチャです。この製品のデプロイメントは、少数のマシンでの小規模な部門アプリケーションから、クラスタ コンフィグレーションでの多数のマシンで構成される非常に大規模なデプロイメントまで多岐にわたります。ある特定のアプリケーションのアーキテクチャと物理デプロイメントは、このドキュメントで後述する複数の要因によって決まります。アプリケーションのニーズを十分に満たすために必要なハードウェアおよびソフトウェア コンフィグレーションのタイプを決定するプロセスをキャパシティ プランニングと呼びます。
このドキュメントでは、WebLogic Portal 10.0 のキャパシティ プランニングに関連する手順について説明します。このドキュメントは、顧客がキャパシティ プランニングのためのより正確な見積もりを作成できるように、測定のベースライン セットとしての役割を果たします。
キャパシティ プランニングは精密科学ではありません。アプリケーションはそれぞれ異なり、ユーザの動作もそれぞれ異なります。このドキュメントは、キャパシティ プランニングの数値を求める際の一種のガイドに過ぎません。利用の際には細心の注意を払うようにしてください。アプリケーションをプロダクション環境にデプロイする前に、アプリケーションの厳密なパフォーマンス テスト サイクルを実行する必要があります。パフォーマンス テストの詳細については、「Approaches to Performance Testing」を参照してください。
| 注意 : | システムをプロダクション環境に移行する前に、このガイドに記載されたすべての推奨事項を十分に検証するようにしてください。前述のように、このドキュメントで公開されているデータは、テスト対象となっている特定のコンフィグレーションを表すものです。システムがサポートできるキャパシティを判断するときには多数の要因が関与します。したがって、プロトタイプを十分にテストすることが、独自のキャパシティ プランニングの数値を求める最善の方法です。 |
WebLogic Portal と特定のアプリケーションをサポートするために、ハードウェア コンフィグレーションにどの程度のキャパシティが必要となるかは、さまざまな要因に左右されます。アプリケーションのサポートに必要なハードウェア キャパシティは、アプリケーションとコンフィグレーションの詳細によって異なります。これらの各要因がコンフィグレーションとアプリケーションにどのように当てはまるかを検討する必要があります。
表 1 に、キャパシティ プランニングのチェックリストを示します。以下の節では、このチェックリストの各項目について説明します。これらの要因を理解し、アプリケーションの要件を検討しておくと、コンフィグレーションに必要なサーバのハードウェア要件を作成する際に役立ちます。
キャパシティ プランニングは、パフォーマンス テスト プロセスにおける最後の手順です。プロダクション デプロイメントに向けてアプリケーションのサイズを設定する準備に入る前に、システムのすべてのボトルネックを解消し、アプリケーションの実行速度をできるだけ高めることができるように、アプリケーションのパフォーマンス テスト プロセスを繰り返し実行する必要があります。
アプリケーションに対してベンチマークを実行すると、測定のベースライン セットが設定されます。これにより、アプリケーションの機能を追加および削除したときに、これらの変更の影響を客観的に測定できます。
開発時にアプリケーションをプロファイルすると、今後大きな問題になる可能性のあるパフォーマンスの問題やパフォーマンス ホットスポットを解消できます。この種の問題を早期に検出することで、後で修正を試みたときに発生するオーバーヘッドを大幅に減らすことができます。
BEA の Dev2Dev サイトにある「Approaches to Performance Testing」を参照してください。
WebLogic Portal 10.0 でサポートされるオペレーティング システムおよびハードウェア コンフィグレーションについては、
WebLogic Platform 10.0 でサポート対象のコンフィグレーションページに記載されています。
多くの場合、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 クラスタは、CPU 2 つにつき 1 つの WebLogic Server インスタンスをデプロイすると最適な規模になります。ただし、すべてのキャパシティ プランニングと同様に、サーバ インスタンスの最適な数と分散方法を決定するときは、対象となるポータル アプリケーションで実際のデプロイメントをテストすることをお勧めします。
システムのパフォーマンス要件を決定するときは、アプリケーションの予想される負荷を考慮に入れる必要があります。たとえば、一般的なバンキング アプリケーションでは、午前 9 時から午後 5 時までの「ピーク時間帯」に大量のトラフィック (多数の同時セッション) が発生します。したがって、キャパシティを見積もるときは、予想される負荷にできるだけ近い負荷をかけてテストするのが最適です。
負荷の一部の要因は、システムの全体的なパフォーマンスに影響を及ぼす可能性があります。これらの要因をどのようにテストするかによって、結果が大きく異なることになります。第一の要因は、システム上のユーザの予想される「思考時間」です。思考時間とは、システム上のアクティブなユーザによるリクエスト間の休止時間です。たとえば、ユーザが銀行口座の残高を確認するためにクリックしたときに、次の 30 秒間再度クリックしない場合、思考時間は 30 秒になります。すべてのユーザの思考時間を平均し (「熟練」ユーザの思考時間は短くなり、「初心者」のユーザほど思考時間が長くなるため)、その値を使用してシステムをテストします。思考時間を減らすと、システムにかかる負荷が大きくなるため、追加のハードウェア リソースが必要となります。
システムをテストするときは、システムにユーザを追加する割合もシステムのパフォーマンス特性に大きな影響を及ぼす可能性があります。たとえば、システムにすべてのユーザを一度に追加した場合、「wave」効果が発生します。これは、応答時間が初期段階で非常に長くなり、ユーザが休止すると大幅に改善しますが、その後、ユーザが引き続きシステム内を移動すると、応答時間が急速に増加する現象です。間隔をおいてユーザを追加することで、この状態が発生するのを防ぐことができ、システムのパフォーマンスをより一貫した状態にすることができます。また、思考時間をある程度ランダムにすると、「wavy」動作を減らすことができ、一貫性のある結果が得られます。
キャパシティ要件を決定するためにシステムをテストするときは、シミュレートしたユーザの負荷がプロダクション環境でのシステムの実際の状況を正確に反映していることを確認します。負荷をシミュレートするときは、システムに同時にかかる負荷が過負荷にならないように細心の注意を払います。
WebLogic Portal の同時ユーザ セッションの最大数を決定します。より多くのユーザを処理するには、スケーラビリティを実現するために適切な CPU キャパシティと RAM が必要となります。サポート対象のほとんどのコンフィグレーションでは、1 GB の RAM が最小コンフィグレーションですが、プロダクション環境の WebLogic Portal の各インスタンスでは 2 GB が推奨されます。
次に、同時にリクエストを行うクライアントの最大数と、各クライアントがリクエストを行う頻度を調べます。WebLogic Portal とユーザ間の 1 秒当たりの対話数は、Portal デプロイメントで毎秒処理される対話の総数を表します。
また、需要の急激な増加に対応するために、特定期間内のトランザクションの最大数も考慮します。システムに、このような急激な増加に対応できるだけのキャパシティがあることを確認します。需要がシステムの最大キャパシティに近い場合は、システムの全体的なパフォーマンスを高め、キャパシティを増やすために、ハードウェアを追加する必要があります。同時ユーザに関するキャパシティについては、「ポータル フレームワークの同時ユーザの結果」を参照してください。
用意されているチューニング ガイドを使用して、WebLogic Server をチューニングする必要があります。
Server のチューニングの詳細については、以下を参照してください。
アプリケーションは適切に設計されていますか。ユーザ アプリケーションが適切に設計されていなかったり、最適化されていなかったりすると、コンフィグレーションのパフォーマンスが大幅に低下する可能性があります。WebLogic Portal 用に開発されたアプリケーションには、いずれも追加のオーバーヘッドを発生させる機能が含まれていると見なし、ベンチマーク アプリケーションと同様のパフォーマンスは期待できないことを前提としてください。念のため、アプリケーションのこのような機能を考慮し、システムのキャパシティを増やすことをお勧めします。
ポータルのサイズ (個々のブック、ページ、およびポートレットの数を合計することによって算出したポータルの分類に基づく) がシステムのパフォーマンスとキャパシティに大きな影響を及ぼす可能性があることに注意する必要があります。ポータルのサイズが増加すると、表示する必要のあるコントロール ツリーも増加するため、システムはポータルのサイズが小さい場合と同様のパフォーマンスを維持できなくなります。
複数レベルのメニューを使用すると、メニュー構造を構築するためにポータル コントロール ツリー内を移動する必要があるため、ツリーの最適化によってもたらされる多くのメリットが失われます。これは、サイズの小さいポータルであれば問題ありませんが、サイズの大きいポータルの場合、システムのパフォーマンスとスケーラビリティに大きな影響を及ぼします。そのため、デプロイメントで必要なハードウェア リソースが増えることになります。
システムのパフォーマンスを最適化するには、サイズの大きいポータルを複数の小さなデスクトップに分割することをお勧めします。また、アプリケーション内のコードの最適化されていない領域を見つけるために、「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 を必要としない場合は、SSL を無効にします。
WebLogic Portal 以外に、何がマシン上で実行されていますか。WebLogic Portal を実行しているマシンでは、プレゼンテーションやビジネス ロジックよりもはるかに多くの処理を実行していることがあります。たとえば、Web サーバを実行していたり、リモート情報フィード (株価サービスの株式情報フィードなど) を保持している可能性があります。ただし、このコンフィグレーションは推奨されていません。
WebLogic Portal マシンの処理能力が、WebLogic Portal とは無関係のプロセスによってどの程度消費されるのかを検討します。WebLogic Portal (または WebLogic Portal がインストールされているマシン) が大量の追加処理を実行している場合は、他のプロセスによってどの程度の処理能力が消費されるかを判断する必要があります。
BEA では、ベンチマーク テスト実行時の WebLogic Portal サーバの CPU 平均使用率が、そのマシンの累積統計として 85 ～ 95% の範囲内であることを推奨しています。たとえば、マシンに複数のプロセッサが搭載されている場合、それらのプロセッサの平均が前述の比率の範囲内であることが望まれます。これにより、マシンがほぼピーク キャパシティで動作できるだけでなく、CPU 使用率が 100% に達することなく、他のシステム プロセスも実行できるようになります。プロダクション時には、応答時間に関する SLA を維持するために、トラフィックの急激な増加に対応するときに CPU オーバーヘッドがシステムに追加されます。
また、WebLogic Portal 以外に、サードパーティのアプリケーション、サービス、またはプロセスをデプロイする場合は、それらのアプリケーション、サービス、またはプロセスを別のハードウェア マシンにデプロイすることをお勧めします。
クラスタ化された WebLogic Portal のデプロイメントに対応するときは、ロード バランシング ソリューションを検討する必要があります。クラスタ内でロード バランシングを行うと、ノード間でユーザ セッションがほぼ均等に分散されます。分散が均等でない場合、WebLogic Portal コンフィグレーションかロード バランサ コンフィグレーションのいずれかに問題があることを示しています。
システムのキャパシティの要求を満たすために、サーバのクラスタが必要な場合は、ロード バランサを実装してマシン間で負荷を分散する必要があります。
サードパーティのすべてのアプリケーションとサービスを別のハードウェアにオフロードします。
データベースはボトルネックになっていますか。追加のユーザ ストレージ要件はありますか。多くのインストール環境では、データベース サーバの方が WebLogic Portal よりかなり早くキャパシティを消費します。アプリケーションを処理するには、十分に堅牢なデータベースをプランニングする必要があります。通常、優れたアプリケーションには、アプリケーション サーバ ハードウェアの 3 - 4 倍強力なデータベースが要求されます。データベース サーバには、別のマシンを使用することをお勧めします。
一般に、WebLogic Portal の CPU 使用率が高い状態を維持できない場合に、データベースがボトルネックになっているかどうかがわかります。これは、WebLogic Portal がほとんどの時間をアイドル状態で費やし、データベースから制御が戻るのを待機していることを示しています。
一部のデータベース ベンダは、アプリケーション サーバのキャパシティ プランニング情報を提供し始めています。通常、これはアプリケーションの 3 層モデルに対応しています。アプリケーションでは、データベースと対話しない操作のためのユーザ ストレージが必要となる場合があります。たとえば、セキュリティで保護されたシステムでは、各ユーザのセキュリティ情報を格納するためのディスクとメモリが必要です。この場合、1 人のユーザの情報を格納するために必要なサイズを計算し、その値と予想されるユーザの最大数を乗算します。
システムでデータベースがボトルネックになるのを防ぐ別の方法もあります。その 1 つは、データベース レイヤでキャッシングを実装する方法です。WebLogic Portal では、データベースをヒットしないようにさまざまなキャッシュを使用します。パフォーマンス テスト時に、データベースがボトルネックであると判断された場合は、WebLogic Portal のキャッシュをチューニングして、データベースから負荷の一部を取り除くことが有用です。
サイズ構成およびパフォーマンスに関連するその他の考慮事項については、WebLogic Portal データベース管理ガイドの「パフォーマンスの考慮事項」 および「サイズ構成の考慮事項」を参照してください。
データベース キャッシュの詳細については、「WebLogic Portal のキャッシュ リファレンス」を参照してください。
帯域幅は十分ですか。リソースの供給が需要に追いつかない場合、ネットワークのパフォーマンスに影響します。WebLogic Server には、処理を必要とするクライアントからのすべての接続を処理できる十分な帯域幅が必要です。HTTP クライアントだけを処理する場合は、静的ページを提供する Web サーバと同様の帯域幅の要件を想定してください。
デフォルトでは、クラスタでのセッション情報のインメモリ レプリケーションは、HTTP クライアントと同じネットワークを共有します。標準ネットワーク トポロジの代替として、内部クラスタ通信に別のチャネルを使用し、外部トラフィックに 2 つ目のチャネルを使用して、物理ネットワークを変更します。詳細については、「ネットワーク リソースのコンフィグレーション 」を参照してください。WebLogic Portal フレームワークで大量のセッション データが作成されることはありませんが、カスタム アプリケーションによって、この領域で大きなオーバーヘッドが追加される可能性があります。また、同時ユーザによる頻繁なリクエストによって大きな負荷がかかると、ネットワークが飽和状態になります。アプリケーションとビジネスのニーズがセッション情報のレプリケーションを必要としているかどうかを検討します。最後に、多数の同時ユーザとサーバに対する頻繁なリクエストの組み合わせを見積もって、ネットワークが予想される負荷を処理できるかどうかを判断します。
デプロイメントで帯域幅が十分かどうかを判断するときは、ネットワーク オペレーティング システム ベンダから提供されているネットワーク ツールを調べてください。Windows および Solaris の組み込みアプリケーションを含め、この測定に役立つ多数の無償ツールと市販ツールがあります。また、ほとんどのハードウェア ロード バランシング ソリューションでは、ネットワーク統計を使用できます。ロード バランサを 1 つしか使用しない場合、負荷が非常に高いと、そのロード バランサもシステムのボトルネックになることがあります。
ギガビット LAN を実行し、1 つまたは複数のサーバ ロード バランサを実装して、ネットワーク トラフィックを最適化することをお勧めします。
どの JVM を使用しますか。どのパラメータを使用しますか。アプリケーションから最高のパフォーマンスを得るにはどれくらいのヒープが必要ですか。アプリケーションを JVM で実行すると、パフォーマンスが向上することがあります。WebLogic Portal では、BEA の JRockit JVM と Sun の HotSpot JVM をサポートしています。全体的に見ると、BEA の JRockit JVM は、Intel プロセッサ上で OS として Linux を使用した「ベンチマーク」テストでパフォーマンスが向上しました。これに対して、HotSpot は、「同時ユーザ」テストでクラスタのサイズを増やしたときにパフォーマンスがわずかに向上しました。
JVM パラメータは、システムのパフォーマンスに非常に大きな影響を及ぼす可能性があります。すべてのパラメータの一覧と、それらのパラメータを使用できる状況については、BEA JRockit リファレンス マニュアルを参照してください。
ヒープのサイズもシステムのパフォーマンスに影響します。アプリケーションの規模が大きくなるほど、必要となるヒープ サイズも増える可能性があります。また、同時ユーザ数が多い場合は、システムがメモリ不足にならないように、ヒープ サイズを増やす必要があります。
どの場合も、JRock では -Xgc:parallel を使用し、HotSpot では-XX:MaxPermSize を最小値の 128m に設定して使用することをお勧めします。アプリケーションによっては、メモリ要件が非常に高くなることがあります。どのような場合にも、さまざまな設定で一連のベンチマーク テストを実行して、アプリケーションにとって何が最適であるかを判断してください。
以下の節には、2 種類のパフォーマンス テスト結果があります。1 つは、スループットを評価するテストであり、もう 1 つはシステムがサポートする同時ユーザの最大数を測定するテストです。これらのテストには、非常に多くの違いがあるため、一方のテストのデータ ポイントをもう一方と比較しないようにしてください。
最初のデータ セットは、「ベンチマーク結果」と呼ばれます。この一連のテストは、1 秒あたりに返されるページ数で測定される、システムのスループットのベースラインを決定するために実行されました。これらのテストの目的は、ポータル サイズ、ポートレット タイプ、および JVM が異なるさまざまなコンフィグレーションでシステムの最大スループットを測定することです。
2 番目のデータ セットは、プロダクション システムに近いシステムで実行されるテストにより密接に関連するため、「同時ユーザの結果」と呼ばれます。この種のテストの目的は、所定の応答時間 (サービス レベル アグリーメントと呼ばれることが多い) の同時ユーザ (Portal からアクティブにクリックしているユーザ) の最大数を測定することです。
各テストは、LoadRunner スクリプトを使用して実行されました。このスクリプトでは、各ユーザは 1 回ログインした後、ページをクリックして進み (「非常に小さい」ポータルを除くすべてのポータルで、50 ページ/ブックのクリック)、最後のページに到達すると、最初のページから繰り返します。非常に小さいポータルのページ数は 8 ページであるため、クリックは 8 回でした。これは、テスト期間が完了するまで続行されました。
以下の節では、パフォーマンス テストで使用したアプリケーションについて説明します。使用したアプリケーションは次のとおりです。
ポータル フレームワーク テスト アプリケーションは、.portal ファイルと .portlet ファイルを含む EAR としてクラスタにデプロイされます。各ポータルでは、ユーザを登録するためにフォームベースの認証を使用しています。ポータル自体のサイズとポートレット タイプはさまざまです。テスト対象の各ポータルに含まれるポートレットのタイプ (JSP、ページ フロー、JSR168 など) は 1 つに限られています。使用したポートレットは、「Hello World」タイプのポートレットのような単純なポートレットと考えられます。ツリーの最適化は、すべてのポータルで有効になっています。資格およびユーザ カスタマイズは無効になっています。すべてのテストで、「replicated_if_clustered」フラグを使用したセッション レプリケーションがコンフィグレーションされました。すべてのユーザにログインを要求しましたが、ログアウトはしなかったため、テストの期間中、各ユーザのセッションが維持されました。
「非常に小さい」ポータル (1 ページあたりのポートレット数は 8 個) を除き、各ポータルには、1 ページあたり 10 個のポートレットがあります。
WSRP テスト アプリケーションは、.portal ファイルと .portlet ファイルを含む EAR として連合クラスタにデプロイされます。各ポータルでは、ユーザを登録するためにフォームベースの認証を使用しています。各ポータルには、8 ページのブックが 1 つあります。各ページには、1 ～ 4 個のリモート ポートレットが含まれています。同じリモート ポートレットの複数のインスタンスが各ページに使用されています (つまり、ページ 1 のポートレット 1 は、そのページのポートレット 2、3、および 4 と同じリモート ポートレット定義を共有しています)。各リモート ポートレットは、同じネットワーク サブネットのリモート マシンにあるポータル プロデューサにアクセスします。ページ 1 と 5 にあるポートレットは、同じプロデューサを指すようにコンフィグレーションされています。ページ 2 と 6、3 と 7、および 4 と 8 のポートレットには、同じパターンのコンフィグレーションが適用されました。図 1 に、このコンフィグレーションを示します。
ポートレットはすべてページ フロー ポートレットです。リモート ポータルは、コンシューマ ポートレットに約 40 KB の HTML コンテンツを提供するように設計されています。ツリーの最適化はすべてのポータルで有効になっていますが、資格とユーザ カスタマイズは無効になっています。すべてのテストで、「replicated_if_clustered」フラグを使用したセッション レプリケーションが有効化されました。すべてのユーザにログインを要求しましたが、ログアウトはしなかったため、テストの期間中、各ユーザのセッションが維持されました。コンシューマとプロデューサ間でユーザ ID を伝播する際に、WSRP SAML ID アサーションを使用する WSRP の SSO 機能は使用しませんでした。
テスト アプリケーションでは、次のようにポートレット サイズと機能を変えました。
キャッシングを有効にすると、キャッシュ TTL がテストの継続期間よりも長い期間に設定されます。
コンシューマ クラスタでのみ、ロード バランシングに F5 Networks Big-IP ロード バランサを使用しました。プロデューサでは、クラスタ化もロード バランシングも行いませんでした。
コンテンツ管理テスト アプリケーションは、コンテンツ API を直接ヒットする JSP ファイルを含む EAR としてクラスタにデプロイされます。これらの JSP は、ノードの作成、ノードへのアクセス、結果セット内のノードに対するページ付け、ノードの読み込みによって発生するセキュリティ オーバーヘッド、および BEA コンテンツ リポジトリ内のノードの読み込みと書き込みの同時実行の各パフォーマンスをテストするように設計されています。使用したノード コンテンツのタイプは、単純型と複合型の 2 種類です。単純型のコンテンツは、5 つの文字列プロパティと 1 つのバイナリ プロパティで構成されます。複合型のコンテンツには、文字列プロパティとカレンダー プロパティがそれぞれ 2 つずつ、ブール プロパティ、バイナリ プロパティ、およびネスト プロパティがそれぞれ 1 つずつ含まれています。ネスト プロパティ自体は、3 つの文字列プロパティ、2 つの long プロパティ、および 2 つのカレンダー プロパティで構成されます。リポジトリ イベントと同様に、リポジトリ管理は無効になっています。リポジトリは読み取り専用ではなく、検索は無効になっています。これらのテストでは、次の要素を変えました。
通常、ノードはリポジトリ ルートの 1 レベル下に作成されます。複合型のネストされたノードはこの例外です。このノードは、ルートの孫として作成されます。
HP Linux の各テストでは、使用するクラスタ コンフィグレーションを変えました。クラスタ内に 2 台、4 台、および 8 台の物理マシンがそれぞれ存在するコンフィグレーションを使用しました。また、各テストでは、管理対象サーバのない単一サーバ コンフィグレーションも使用しました。クラスタ コンフィグレーションでは、各マシンで管理対象サーバが 1 つ実行されており、このサーバは各物理マシン上で 1 つのポータルおよび 1 つの JVM になります。各 WLP サーバは 2 つの CPU を搭載しています。表のデータは、CPU カウントで示されています。
-Xms1536m -Xmx1536m -Xgc:parallel を設定した BEA JRockit JVM -server -Xms1536m -Xmx1536m -XX:MaxPermSize=128m を設定した Sun HotSpot JVM
Sun Solaris のテストでは、1 台の物理マシンで構成された 4 CPU のコンフィグレーションと、2 台の物理マシンで構成された 8 CPU のコンフィグレーションを使用しました。各マシンで 2 つ (クラスタ内で計 2 つおよび 4 つ) の管理対象サーバが実行されており、これらのサーバは各物理マシン上で 2 つのポータルおよび 2 つの JVM になります。各サーバは 4 つの CPU を搭載しています。表のデータは、CPU カウントによって示されています。
-server -Xms1536m -Xmx1536m -XX:MaxPermSize=128m を設定した Hotspot
「ベンチマーク」テストは、さまざまな条件下でのシステムの最大スループットを示すことを目的としています。このテストでは、ポータル内のポートレットのタイプとポータルのサイズ、および JVM を変えました。各コンフィグレーションの目的は、サーバを飽和状態にして最大スループットに達するようにすることです。WebLogic Portal サーバの CPU 使用率は、85 ～ 95 % (最大スループットに最適な範囲) に達しました。
最大スループットを実現するために、ゼロ秒の「思考時間」を使用しました。これは、サーバからの応答と後続のリクエスト間の時間がゼロ秒であるということです。この種の負荷をかけると、比較的少ないユーザ数で短期間のうちにサーバを飽和状態にし、最大スループットを達成することが非常に容易になります。
ベンチマーク テストでは、1 CPU あたり 10 仮想ユーザ (LoadRunner の VUser) を使用しました。ベンチマークは、HP Linux と Sun Solaris の 2 つのハードウェア コンフィグレーションで実行されました。テスト対象の Linux マシンはすべて 2 CPU でコンフィグレーションされており、WebLogic Portal クラスタ内の各ノードでは、マシン 1 台につき 20 仮想ユーザを使用しました。テスト対象の Sun Solaris マシンは 4 つの CPU を搭載しているため、マシン 1 台につき 40 仮想ユーザを使用しました。これらのユーザを 25 分の間に「ランプアップ (システムに追加)」した後、さらに 10 分間、定常状態 (別のユーザを追加せずに既存のユーザが引き続きシステムにアクセスしている状態) を持続させました。
| 注意 : | この調査で使用したベンチマークで得られたベースライン値を使用して、WebLogic Portal と、同様のベンチマークを実行した他のポータルやハードウェアを比較しないようにしてください。この調査で使用したベンチマーク方式とチューニングは独自のものです。 |
サーバは、WebLogic Server 9.0 以降の新機能である自動チューニングに設定しました。JDBC 接続プールは、5 接続から開始し、25 接続まで拡張できるように設定しました。これらのテストは、サーバがすぐに飽和状態になるように、思考時間を 0 秒にして実行しました。
サーバは、WebLogic Server 9.0 以降の新機能である自動チューニングに設定しました。JDBC 接続プールは、5 接続から開始し、25 接続まで拡張できるように設定しました。これらのテストは、サーバがすぐに飽和状態になるように、思考時間を 0 秒にして実行しました。
パフォーマンス テストのこの結果セットは、特定のハードウェア セットで実行できる同時ユーザ数を測定して、システムの全体的なキャパシティを決定するのに最も適しているため、「キャパシティ プランニング」結果とも呼ばれます。これらのテストは、実際のユーザ負荷を模倣するように設計されているため、標準的な「ベンチマーク」テストよりも正確にシステムの状態を表します。
顧客からのフィードバックに基づくと、最も一般的な SLA は、応答時間が 2 秒または 5 秒です。テストの目的は、このような SLA を設定したさまざまなコンフィグレーションで、WebLogic Portal がサポートできるユーザ数を測定することです。指定した SLA が高いほど、サポートされるユーザ数も増加しますが、実際に追加テストを実行しないと、この数を見積もるのは困難です。
キャパシティ プランニング テストでは、思考時間についても、いわゆる「熟練ユーザ」がアクセスする実際のプロダクション システムを模倣します。これは、エンド ユーザによるリクエスト回数が「熟練ユーザ」の場合とは異なるシステムおよび他の多くのコンフィグレーションでは非常に高い負荷と見なす必要があります。これらのテストの思考時間は、5 秒 +/- 25% ( 3.75 ～ 6.25 秒) でランダムに設定されました。これに対して、熟練者ではないユーザがアクセスするようなシステムでは、全ユーザの平均値として思考時間は 30 秒近くになると考えられます。システムの思考時間は、Portal の全体的なキャパシティに大きな影響を及ぼします。思考時間が長くなると、システムを使用できるユーザ数が増加することになります。「ベンチマーク」コンフィグレーションでは、システムを飽和状態にするために必要なユーザ数は、1 CPU あたり 10 ユーザに過ぎませんが、思考時間を設定した場合、同じ影響を与えるために、1 CPU あたり数千とはいかないまでも数百のユーザが必要になる可能性があります。
キャパシティ プランニング テストでの負荷は、上記の「ベンチマーク」テストの負荷とは大きく異なります。思考時間によって、最低限の SLA を満たすために必要なユーザ数がはるかに多いため、テストの継続期間を延長する必要があります。各コンフィグレーションのユーザ数を 1 時間の間にランプアップし、各コンフィグレーションでは、30 秒ごとに一定の割合で異なる数のユーザを追加しました。1 時間を選択したのは、システムの応答が向上し、これよりも短いランプアップ スケジュールでより多くのユーザがサポートされたためです。約 1 時間を目安にすべてのユーザが実行されるまで、多数のユーザをシステムに追加しました。
このテストにより、テスト ポータルが所定の応答時間でサポートできる同時ユーザ数が明らかになりました。目標応答時間として、2 秒と 5 秒を使用しました。表に示す同時ユーザ数は、応答時間が 2 秒または 5 秒での最大同時実行ユーザ数を表します。このテストでは、HP Linux コンフィグレーションを使用しました。「HP Linux ハードウェアおよびサーバのコンフィグレーション」を参照してください。各サーバは 2 つの CPU を搭載しています。表のデータは、CPU カウントによって示されています。
PageFlow ポートレットは、パフォーマンスに影響する可能性のある追加のメモリ要件を持つ場合があります。この詳細については、『パフォーマンス チューニング ガイド』の「PageFlow ポートレットのチューニング」、および『ポータル開発ガイド』に記載されています。この節の数値は、これらの制限事項の対象となります。
WSRP のベンチマーク テストは、さまざまな条件下での連合システムの最大スループットを示すことを目的としています。このテストでは、ポータル内のポートレット数、キャッシング、および JVM を変えました。
各コンフィグレーションの目的は、インフラストラクチャを飽和状態にして最大スループットを達成することです。WebLogic Portal サーバの CPU 使用率は、85 ～ 95 % (最大スループットに最適な範囲) に達しました。テストでは、プロデューサの数を 2 つに固定しました。コンシューマ クラスタに管理対象サーバを追加すると、プロデューサが対応できず、最終的にシステムのボトルネックになりました。プロデューサ クラスタの CPU は、最適範囲を超えるまで増加し、コンシューマ クラスタの全体的なパフォーマンスに影響しました。このテストの場合、コンシューマ クラスタ内の 3 つの管理対象サーバに対して 2 台のプロデューサ マシンというコンフィグレーションが最適なコンフィグレーションです。
最大スループットを実現するために、ゼロ秒の「思考時間」を使用しました。これは、サーバからの応答と後続のリクエスト間の時間がゼロ秒であるということです。この種の負荷をかけると、比較的少ないユーザ数で短期間のうちにサーバを飽和状態にし、最大スループットを達成することが非常に容易になります。これらのテストでは、負荷を最大にするために、1 CPU あたり 50 仮想ユーザ (LoadRunner の VUser) を使用しました。
これらのユーザを 40 分の間に「ランプアップ (システムに追加)」した後、さらに 20 分間、定常状態 (別のユーザを追加せずに既存のユーザが引き続きシステムにアクセスしている状態) を持続させました。
さまざまな JVM に、コンフィグレーション パラメータが無数にあります。これらの各パラメータは、アプリケーションの全体的なパフォーマンスに特定の影響を及ぼす可能性があります。JRockit JVM と Sun の HotSpot JVM では、次の JVM パラメータを設定して実行しました。
WSRP アプリケーションのパフォーマンス チューニングの詳細については、『パフォーマンス チューニング ガイド』の「WSRP のチューニング」を参照してください。
図 2 は、このデータをグラフで表したものです。X 軸では、実行したコンフィグレーションに従って、データを区切っています。最も低い数値セットは、左端の「PORTAL_SIZE」ブロックに対応しています。これは、テスト コンフィグレーションでのポートレット数です。中央の数値セットは、下の「NUM_CPUS」ブロックに対応します。これは、クラスタに含まれる CPU の数です。最も高い値を示すコンフィグレーションは、キャッシングを有効にするかどうかに関連します。これは、グラフの下の右端の「CACHE」ブロックに対応しています。
図 3 は、このデータをグラフで表したものです。X 軸では、実行したコンフィグレーションに従って、データを区切っています。最も低い数値セットは、左端の「PORTAL_SIZE」ブロックに対応しています。これは、テスト コンフィグレーションでのポートレット数です。中央の数値セットは、下の「NUM_CPUS」ブロックに対応します。これは、クラスタに含まれる CPU の数です。最も高い値を示すコンフィグレーションは、キャッシングを有効にするかどうかに関連します。これは、グラフの下の右端の「CACHE」ブロックに対応しています。
コンテンツ管理ベンチマーク テストは、コンテンツ管理 API およびインフラストラクチャにさまざまなタイプの負荷をかけたときの影響を示すことを目的としています。これは、最大キャパシティまでシステムに負荷をかけるようにし、さまざまなコンフィグレーションでテストする「ベンチマーク」スタイルのテストです。このドキュメントの他のテスト結果では、スループットの計算を使用してパフォーマンス統計を測定しましたが、このコンテンツ テストでは、指標として応答時間を使用しています。応答時間は、サーバがクライアントからの 1 つのリクエストを処理し、クライアントに応答が返されるまでの所要時間です。他のテストでは、パフォーマンス測定の一環として、表示された HTML を使用しました。コンテンツ テストは、(HTML の表示ではなく) 主にネイティブ API の実行を対象としているため、測定は表示できる HTML の量ではなく、API の応答速度に関するものです。
コンテンツ管理ベンチマーク テストは、クラスタ コンフィグレーションではないスタンドアロンの 1 台のマシンで実行されました。このテストでは、コンテンツのデータベース スキーマは任意の場所に配置できますが、コンテンツ スキーマは WebLogic Portal スキーマと同じ場所に配置しました。
このテストは、このドキュメントのその他のテストで使用したランプアップ/継続時間モデルには従っていません。代わりに、テスト開始時点からすべてのユーザを同時に実行し、固定回数反復するために API リクエストを繰り返しました。この反復は、データベース内のノード数にほぼ対応しています。テストの継続時間は、データベースのすべてのコンテンツが 1 回表示された時点ですべてのキャッシュを定期的にフラッシュし、このサイクルを繰り返すことによって制御しました。どの場合も、リクエスト間にはゼロ秒の「思考時間」を使用しました。これにより、短期間でサーバに最大量の負荷をかけました。
すべてのコンテンツ テストは、JRockit JVM を使用して実行しました。
コンテンツ管理のパフォーマンスを向上させる方法については、『パフォーマンス チューニング ガイド』の「コンテンツ管理のチューニング」を参照してください。
このテストでは、コンテンツ API によってコンテンツ管理システム内にノードを作成する際に必要な応答時間を測定しました。テストには、バイナリ データをバイナリ プロパティにインポートするための数値が含まれています。このバイナリ データは、webapp 内のファイルにあります。このデータは、初めてリクエストされたときにメモリ内のバイナリ オブジェクトにロードされ、連続する各リクエストではメモリから読み込まれます。
使用したコンテンツのタイプは、単純型と複合型の 2 種類です。これらは、「コンテンツ管理アプリケーション」で定義されています。
このテストは、コンテンツ リポジトリからランダム ノードを取得する際の所要時間を測定することを目的としています。各テストでは、コンテンツ リポジトリからランダム ノードを取得する際に、次の方法のいずれかを使用しました。
キャッシングを確実に無効にするために、各ノードを 1 回だけ取得しました。
使用したコンテンツのタイプは、単純型と複合型の 2 種類です。これらは、「コンテンツ管理アプリケーション」で定義されています。
このテストは、さまざまなページ付け方法がパフォーマンスに及ぼす影響を測定するために使用しました。テストでは、同時実行性のレベルとページ付けバッチ サイズ (ページごとに返されるコンテンツ ノードの数) を変えました。このテストでは、実際のアプリケーションがリポジトリからデータを読み込む方法をレプリケートし、ページ付けしたデータを表示しました。テストでは、コンテンツ API に用意された次のページ付けメソッドを比較しました。
使用したコンテンツのタイプは、単純型と複合型の 2 種類です。これらは、「コンテンツ管理アプリケーション」で定義されています。
コンテンツ セキュリティ テストは、コンテンツ管理システムのセキュリティ メカニズムにおける暗黙的オーバーヘッドを測定することを目的としています。このテストは、管理者パーミッションを持たないユーザとページ付けされたコンテンツを表示するユーザによって実行されました。テスト コンフィグレーションに応じて、全体的比率が異なるコンテンツ リポジトリ ノードがユーザに表示されます。これは、ノードの資格によって管理され、テストではノードの資格の比率として 50% と 100% を使用しました。「コンテンツ ページ付けの結果」は、ページ付けバッチ サイズを増やすと、平均応答時間がわずかに短縮されることを示しています。バッチ サイズを 10 倍に増やすと、平均応答時間がわずかに短縮されます。このテストではこの点を考慮に入れ、ページ付けバッチ サイズを 100 に固定しました。
使用したコンテンツのタイプは、単純型と複合型の 2 種類です。これらは、「コンテンツ管理アプリケーション」で定義されています。
コンテンツ同時テストでは、複数のユーザによってコンテンツ リポジトリのデータの作成と読み込みが同時に行われたときの影響を測定しました。このテストは、コンテンツ管理システムの現実的な使用事例に基づいてモデル化されました。テストは、すでに 100,000 ノードを含むリポジトリに対して実行されました。テストでは、5000 ノードまたは 10000 ノードを追加すると同時に、データベースからノードを読み込みました。読み込み操作を実行するユーザは、コンテンツ API メソッド、INodeManager.getNodeByUUID(ContentContext, ID) を呼び出すことによって、操作を実行しました。
使用したコンテンツのタイプは、単純型と複合型の 2 種類です。これらは、「コンテンツ管理アプリケーション」で定義されています。
WebLogic Portal では、WebLogic Platform のさまざまなコンポーネントを使用します。WebLogic Portal のチューニングの詳細については、以下のドキュメントを参照してください。
|
