|
|
Oracle WebLogic Portal は、充実したウェブ 2.0対話によってパーソナライズされたウェブ経験を提供する先端の Java portal です。WebLogic Portal を使用して大小企業に膨大なビジネス ソリューションを提供してきました。WebLogic Portal はエンタープライズ クラス ポータル ソリューションの配信に対する規格を設定して、最も需要の多いデプロイメントのスケーラビリティとパフォーマンス要件を満たすように設計されています。WebLogic Portal ソリューションは、部門アプリケーションから存在する最大規模の企業デプロイメントまでを網羅します。デプロイメント アーキテクチャには独立したサーバまたはステート レプリケーションがある高度なクラスタ コンフィグレーションを含みます。WebLogic Portal はソリューション要件を満たすよう柔軟に設計されています。特定の実装のアーキテクチャと物理デプロイメントは、多くの要因に依存していますが、それについてはこのドキュメントで後ほど説明します。デプロイメントに必要であるハードウェアとソフトウェア構成を評価するプロセスをキャパシティ プランニングといいます。
このドキュメントでは、WebLogic Portal のキャパシティ プランニングに関連する手順について説明します。このドキュメントは、顧客がキャパシティ プランニングのためのより正確な見積もりを作成できるように、測定のベースライン セットとしての役割を果たします。
キャパシティ プランニングは精密科学ではありません。各アプリケーション プロイメントとユーザはユニークであり、テストはすべての相互作用を予期できません。このドキュメントは特定のデプロイメントに対する処方箋や推奨事項ではなく、キャパシティ プランニングの数値を開発するためのガイドです。ソリューションを設計しているときおよびコンフィグレーションをテストしているとき十分に検討した上でビジネス予想、要求における定期的な変動およびアプリケーション規制に注意する必要があります - いくつかのデプロイメントは同一です。顧客は注意深く設計、組織的にテスト、最低ではなく余分なキャパシティでデプロイされた保守的な原則を取り入れることが必要です。プロダクション環境にいずれかのアプリケーションをデプロイする前に、アプリケーションで綿密なパフォーマンス テスト サイクルを行う必要があります。パフォーマンス テストの詳細について、Oracle Technology Network Web サイトの「Approaches to Performance Testing」を参照してください。
| 注意 : | システムをプロダクション環境に移行する前に、このガイドに記載されたすべての推奨事項を十分に検証するようにしてください。前述のように、このドキュメントで公開されているデータは、テスト対象となっている特定のコンフィグレーションを表すものです。システムがどの程度のキャパシティをサポートするかを判断する場合にさまざまな要因を考える必要があるため、プロトタイプの十分なテストを実行することなしに独自のキャパシティプランニングの数値を取得することはできません。物理的なアーキテクチャ、キャパシティ プランニング、パフォーマンス テスティングおよび災害復旧の計画に経験がないグループの場合、支援が必要となります。 |
特定の WebLogic Portal デプロイメントの要求の見積もりをするには多数の要素を比較検討する必要があります。アプリケーションのサポートに必要なハードウェア キャパシティは、アプリケーション、サーバ ハードウェア、ネットワーク インフラストラクチャおよびポータル コンフィグレーションの詳細によって異なります。それぞれの要因が実装にどう影響するのかを考える必要があります。
表 1 に、キャパシティ プランニングのチェックリストを示します。以下の節では、このチェックリストの各項目について説明します。これらの要因を理解し、アプリケーションの要件を検討しておくと、コンフィグレーションに必要なサーバのハードウェア要件を作成する際に役立ちます。
キャパシティ プランニングは、パフォーマンス テスト プロセスにおける最後の手順です。アプリケーションをプロダクション デプロイメントに準備する前に、ボトルネックがなく、応答動作の要件を満たすように反復パフォーマンス テストを実行する必要があります。
アプリケーションに対してベンチマークを実行すると、測定のベースライン セットが設定されます。これにより、アプリケーションの機能を追加および削除したときに、これらの変更の影響を客観的に測定できます。
開発時にアプリケーションをプロファイルすると、今後大きな問題になる可能性のあるパフォーマンスの問題やパフォーマンス ホットスポットを解消できます。この種の問題を早期に検出することで、後で修正を試みたときに発生するオーバーヘッドを大幅に減らすことができます。
プロダクション モニタ システムは、特定の問題領域を認識し数値で表すためのプロダクション デプロイメントおよび QA テスティングへの便利な追加機能です。プロダクション デプロイメントに含まれているモニタ ツール、ロード バランサと侵入検知ソフトウェアなどができるだけテスト環境にレプリケートされる必要があります。多くのテスト構成には、テストができるだけ正確に実行されるように、合成ネットワーク トラフィック ジェネレータが含まれています。
Oracle Technology Network Web サイトの「Approaches to Performance Testing」を参照してください。
WebLogic Portal の現在のバージョンに対して Oracle がサポートするオペレーティング システムおよびハードウェアのコンフィグレーションについては、「WebLogic Platform でサポートされているコンフィグレーション」に記載されています。
WebLogic Portal でデプロイした特定のアプリケーションはパフォーマンス特性と一致しない場合、ハードウェアが十分であるかを確認します。これは、システムが適切にスケールされているかを判断する時の最も重要な要因です。Oracle の内部パフォーマンス テストの時、WebLogic Portal は CPU にバインドしているため、システムのパフォーマンスは CPU のスピードと CPU の合計数に依存します。
Oracle の内部パフォーマンス テストは、システム パフォーマンスと CPU の全体的なクロック スピード間の直接関係を示します。1 つ以上の CPU または高スピードの CPU を追加すると、システムのキャパシティが増加されます。また、マシンをクラスタ化することにより、アプリケーションのデプロイメント全体に CPU が追加されるため、WebLogic Portal のスケーラビリティが向上します。新しいプロセッサ技術もシステムの動作を決定する際の大きな要因となります。たとえば、結果のセクションでは、異なる CPU アーキテクチャで実行されるテストのデータの一連および結果として取得する重要な相違点があります。
処理速度が最も速いと考えられる 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 までの「ピーク時間」に重いトラフィック (多数の同時セッション) となります。キャパシティを見積もる時、予期される負荷とできるだけ同じ負荷でテストを行うのが最適です。また、一部のテスティング グループは使用方法を識別するために実際のエンド ユーザ テスティング サイクルを含みます。
さまざまな負荷の要因は、システムの全体的なパフォーマンスに影響を与え、これらの要因がどのようにテストされるかによって結果が異なります。第 1 の要因は、各アプリケーションの予期された「思考時間」です。思考時間とは、システム上のアクティブなユーザによるリクエスト間の休止時間です。たとえば、ユーザが銀行口座の残高を確認するためにクリックしたときに、次の 30 秒間再度クリックしない場合、思考時間は 30 秒になります。すべてのユーザ (「エキスパート」ユーザの思考時間は短くて、「新しい」ユーザの思考時間は長いため) の思考時間の平均値を計算します。思考時間はアプリケーションによって異なり、システム テストに反映される必要があります。思考時間を減少させると、システムをテストする際に、システムにユーザを追加する割合がシステムのパフォーマンス特性に大きな影響を及ぼす可能性もあります。すべてのユーザがシステムに同時に追加されると、「wave」効果が発生し、これは、最初に応答時間が非常に増加しますが、次にユーザがシステムを通じて移動すると急速に増加します。ユーザを間隔をおいて追加すると、上記の状態を回避することができ、システムは一貫性のあるパフォーマンスで動作するようになります。思考時間をランダムに定義すると、テストが実際的に行われ、「wavy」動作が減少され、正確でより一貫性のある結果が得られます。
キャパシティ要件を決定するためにシステムをテストするときは、シミュレートしたユーザの負荷がプロダクション環境でのシステムの実際の状況を正確に反映していることを確認します。また、これは実際のエンド ユーザ タイミングを設定し、特定の使用パターンのモデル テストを使用して実現できます。不正な結果を生成する過度の負荷のシミュレートに注意します。
WebLogic Portal の同時ユーザ セッションの最大数を決定します。より多くのユーザを処理するには、スケーラビリティを実現するために適切な CPU キャパシティと RAM が必要となります。サポート対象のほとんどのコンフィグレーションでは、1 GB の RAM が最小コンフィグレーションですが、プロダクション環境の WebLogic Portal の各インスタンスでは 2 GB が推奨されます。
次に、同時にリクエストを行うクライアントの最大数と、各クライアントがリクエストを行う頻度を調べます。これはユーザの合計数の分数を使用して行うことができますが、より良いメソッドは 既存のシステムを測定することです。WebLogic Portal とユーザ間の 1 秒当たりの対話数が、Portal デプロイメントで 1 秒間に処理する必要がある合計対話数になります。
また、リクエスト数が急激に増えた場合に対応するために、指定した期間内のトランザクションの最大数に着目する必要があります。システムに対して最大キャパシティの需要がある場合は、全体的なシステムのパフォーマンスとキャパシティを向上させるためにハードウェアを追加する必要があります。同時ユーザに関するキャパシティについては、「ポータル フレームワークの同時ユーザの結果」を参照してください。
用意されているチューニング ガイドを使用して、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 server 上のCPU の平均使用率は、ベンチマーク テストを実行する時に、そのマシンの累積統計として、85%～95% の範囲であることをお勧めします。たとえば、マシンに複数のプロセッサが搭載されている場合、それらのプロセッサの平均が前述の比率の範囲内であることが望まれます。これにより、マシンがほぼピーク キャパシティで動作できるだけでなく、CPU 使用率が 100% に達することなく、他のシステム プロセスも実行できるようになります。プロダクション環境の時、応答時間に近い SLA が維持されるように、トラフィック内の急激な増加に対応するため、追加の CPU オーバーヘッドをシステムに加える必要があります。プロダクションにおける基本ルールは予期しないイベントが発生した場合に余分な CPU 容量を使用できるように 70% 未満の 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 は、Oracle の JRockit および Sun の HotSpot JVMs をサポートします。一般的には、Oracle の JRockit JVM は、Intel プロセッサを使用した Linux OS における「ベンチマーク」テストでのパフォーマンスが良く、HotSpot は、「同時ユーザ」テストにおいてクラスタのサイズを増やすとパフォーマンスがやや上回りました。
JVM パラメータは、システムのパフォーマンスに非常に大きな影響を及ぼす可能性があります。すべてのパラメータの一覧および使用先について、「Oracle 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 は、ノードの作成、ノードへのアクセス、結果セット内のノードに対するページ付け、ノードの読み込みによって発生するセキュリティ オーバーヘッドおよび WLP コンテンツ リポジトリ内のノードの読み込みと書き込みの同時実行の各パフォーマンスをテストするように設計されています。使用したノード コンテンツのタイプは、単純型と複合型の 2 種類です。単純型のコンテンツは、5 つの文字列プロパティと 1 つのバイナリ プロパティで構成されます。複合型のコンテンツには、文字列プロパティとカレンダー プロパティがそれぞれ 2 つずつ、ブール プロパティ、バイナリ プロパティ、およびネスト プロパティがそれぞれ 1 つずつ含まれています。ネスト プロパティ自体は、3 つの文字列プロパティ、2 つの long プロパティ、および 2 つのカレンダー プロパティで構成されます。リポジトリ イベントと同様に、リポジトリ管理は無効になっています。リポジトリは読み取り専用ではなく、検索は無効になっています。これらのテストでは、次の要素を変えました。
通常、ノードはリポジトリ ルートの 1 レベル下に作成されます。複合型のネストされたノードはこの例外です。このノードは、ルートの孫として作成されます。
HP Linux では、1 つのクラスタで、2 個または 4 個の物理マシンのようなさまざまなクラスタ コンフィグレーションでテストします。各物理マシン上で、1 つの JVM に実行されるポータルがあります。旧リリースのハードウェア取得コストを続行するには、アップグレードしたハードウェアで現在の性能テストを実行しました。旧ハードウェアと同じプライスでアップグレードしたハードウェアを購入しました。旧リリースに対して現在結果の比較の詳細については、「旧リリースに対して現在結果の比較」を参照してください。
-Xms2048m -Xmx2048m -Xgc:parallel を設定した Oracle JRockit JVM。 -server -Xms2048m -Xmx2048m -XX:MaxPermSize=128m を設定した Sun HotSpot JVM。
Sun Solaris のテストでは、1 台の物理マシンで構成された 4 CPU のコンフィグレーションと、2 台の物理マシンで構成された 8 CPU のコンフィグレーションを使用しました。各マシンで 2 つ (クラスタ内で計 2 つおよび 4 つ) の管理対象サーバが実行されており、これらのサーバは各物理マシン上で 2 つのポータルおよび 2 つの JVM になります。各サーバは 4 つの CPU を搭載しています。表のデータは、CPU カウントによって示されています。
-server -Xms2048m -Xmx2048m -XX:MaxPermSize=128m を設定した Hotspot。
このリリースでのハードウェア アップグレードによって、WLP 10.0 と比較した場合、HP Linux で行われるテストの 4 倍のパフォーマンス向上を期待できます。これは Dual-Core 2 chip G4 から Quad-Core 2 chip G5 へのアップグレードとフロント-サイド バスの改善によって説明されます。このハードウェア アップグレードで CPU 集約型のコンフィグレーション (JSP, JSR168) を最適化できます。ページ フローの場合、マシンの物理メモリの制約があるので、利点は少なくなります。
「ベンチマーク」テストは、異なる状況におけるシステムの最大スループットを示すために設計されています。このテストでは、ポータル内のポートレットのタイプとポータルのサイズ、および JVM を変えました。各コンフィグレーションの目的は、サーバを飽和状態にして最大スループットに達するようにすることです。WebLogic Portal サーバの CPU 使用率は、85 ～ 95 % (最大スループットに最適な範囲) に達しました。
最大スループットを取得するために、「思考時間」に対してゼロ秒を使用しました。つまり、サーバからの応答と後続のリクエスト間の時間は 0 秒でした。この種の負荷をかけると、比較的少ないユーザ数で短期間のうちにサーバを飽和状態にし、最大スループットを達成することが非常に容易になります。
ベンチマーク テストでは、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 の全体的なキャパシティに大きな影響を及ぼします。思考時間が長くなると、システムを使用できるユーザ数が増加することになります。「ベンチマーク」コンフィグレーションでは、システムを飽和するには CPU あたり 10 ユーザだけ必要ですが、思考時間を考えると、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 台のプロデューサ マシンというコンフィグレーションが最適なコンフィグレーションです。
最大スループットを取得するために、「思考時間」に対してゼロ秒を使用しました。つまり、サーバからの応答と後続のリクエスト間の時間は 0 秒でした。この種の負荷をかけると、比較的少ないユーザ数で短期間のうちにサーバを飽和状態にし、最大スループットを達成することが非常に容易になります。これらのテストでは、負荷を最大にするために、1 CPU あたり 50 仮想ユーザ (LoadRunner の VUser) を使用しました。
これらのユーザを 40 分間「ランプアップ」 (システムに追加) した後、定常状態 (ユーザを追加せずに、既存のユーザがシステムにアクセスしている状態) がさらに 20 分間続きました。
さまざまな JVM に、コンフィグレーション パラメータが無数にあります。これらの各パラメータは、アプリケーションの全体的なパフォーマンスに特定の影響を及ぼす可能性があります。Jrockit JVM と Sun の HotSpot JVM では、次の JVM パラメータを設定して実行しました。
WSRP アプリケーションのパフォーマンス チューニングの詳細については、『パフォーマンス チューニング ガイド』の「WSRP のチューニング」を参照してください。
このデータは図 2 にグラフィカルに表現されています。測定したスループット データはそれぞれ一意のコンフィグレーションに対して 1 つの縦棒で表示します。X- 軸で、実行されたコンフィグレーションに従って、データを分割します。最も低い数字セット (8、16、32) は、左端のブロック 「PORTAL_SIZE」に対応します - テストコンフィグレーションのポートレットの数を表します。コンフィグレーション間の変数はキャッシングが ON であるかによってことなります。これは「CACHE」の図での 2 番目のコラムに対応します。グラフの上部の変数は図の「JAVA_VENDOR」コラムに対応し、Oracle (Jrockit) または Sun (Hotspot) に設定されます。このデータは「CLUSTER_SIZE」を表す 2 つのバー (2 つのノード (4 CPU) または 3 つのノード (6 CPU)) に分類されます。グラフの下部に各コンフィグレーションに対する生の数値を割り当てます。
コンテンツ管理ベンチマーク テストは、コンテンツ管理 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 のチューニングの詳細については、以下のドキュメントを参照してください。
|