|
|
ポータルのパフォーマンスの重要な側面は、ポータル アプリケーション レベルで管理されます。以下のものが含まれます。
WebLogic Portal には、キャッシュのコンフィグレーション、アクセス、モニタ、および管理に使用できる単一のフレームワークが用意されています。キャッシュを正しくコンフィグレーションすれば、頻繁に使用するデータの検索にかかる時間を大幅に短縮できます。キャッシュは読み込み専用であり、クラスタ対応であることに注意してください。
WebLogic Portal サービスの多くは、あらかじめコンフィグレーションされているキャッシュを使用しています。これらのキャッシュは、ユーザのパフォーマンスのニーズに合わせてチューニングできます。ユーザがコンフィグレーションしたり、アクセスしたりすることができない、内部的にコンフィグレーションされたキャッシュを使用するサービスもあります。サービスを拡張または作成した場合は、キャッシュ フレームワークを使用して独自のキャッシュ セットを定義し、使用することができます。
『キャッシュ リファレンス』には、ポータル アプリケーションで使用されるキャッシュの一覧が記載されています。この一覧を参考にしてチューニングを行います。システムで使用できるメモリに留意してください。最大キャッシュ サイズを変更するときには、システム メモリもモニタしてその影響を判断します。
静的に定義されたキャッシュをコンフィグレーションするには、WebLogic Portal Administration Console 内のサービス管理ツールを使用します。コンフィグレーション可能なキャッシュの一覧については、『キャッシュ リファレンス』を参照してください。
キャッシュをコンフィグレーションするときは、パラメータを修正してキャッシュの動作または機能を変更します。各キャッシュには、最大サイズ設定と生存時間設定があります。たとえば、最新の 10,000 エントリのみを保持するようにキャッシュを設定したり、キャッシュ内のエントリの生存時間を設定したりできます。また、キャッシュをフラッシュして、情報に対するすべての新しい要求をデータベースから直接受け取ることもできます。
キャッシュ設定のコンフィグレーションの手順については、『キャッシュ リファレンス』の「キャッシュの追加」を参照してください。
一部の WebLogic Portal JSP タグは、セッションやページなどのさまざまなスコープでの結果のキャッシングをサポートします。これにより、個々のコンテンツ クエリのキャッシングをさらに詳細に管理できます。これは 1 つの利点とも考えられますが、コーディングによってキャッシュを制御すると、アプリケーションのサイズ (コードの量) によっては、キャッシュの変更で必要となるメンテナンスが増えることになります。
たとえば、コンテンツ管理に関連する以下の JSP タグには、キャッシュ関連の属性が含まれます。
これらの JSP タグとその属性の詳細については、
WebLogic Portal Javadoc を参照してください。
新しいポータル アプリケーションを作成すると、WebLogic Portal では、コマース サービス、イベント リスニング、キャンペーンなど、ほとんどのサービスが有効になります。ポータル アプリケーションでこれらのサービスが不要な場合は、サービスを無効にすることによってパフォーマンスを向上させることができます。
行動追跡または個々のイベントを無効にすることができます。この方法の詳細については、『対話管理ガイド』を参照してください。
キャンペーンは、パーソナライゼーションのための強力なツールです。キャンペーンにより、アプリケーションはきめ細かいルールに基づいて特定の Web コンテンツ、電子メール、および割引を対象ユーザに提供できます。以下のヒントに従ってキャンペーン設定をチューニングすることで、パフォーマンスを向上させることができます。
常にシナリオ ルールを特定のイベントに依存させます。それによって、シナリオ ルール内で参照されているイベント タイプに基づく最適化が可能です。
できる限り、余分なイベントを生成しないようにします。キャンペーン サービスは、すべてイベントをリスンする必要があります。イベントは、サイトで発生した重要なできごとを通知する際に使用してください。
キャンペーンを非同期に設定すると、キャンペーンを表示するエンド ユーザに対する応答時間が短縮される場合があります。これは、AsynchronousEventListener メカニズムによって実現されます。
この最適化は、同じ要求内でキャンペーン結果が必要ではない場合に役立ちます。サーバが受信する次の要求 (必ずしも最初の要求を行ったユーザからのものであるとは限りません) の前にキャンペーンを実行する場合、キャンペーンを非同期に設定すると、キャンペーンのパフォーマンスを向上させることができます。たとえば、ユーザがログインした場合、ログイン フォームの直後の画面にキャンペーン コンテンツのプレースホルダが必ずしも表示されるとは限りませんが、次のページの変更または更新前には表示されます。マルチスレッド アプリケーションの性質上、すぐ次の画面でユーザに結果が表示されることもありますが、この保証はありません。
キャンペーンを非同期に設定しても、サーバの全体的な負荷が減るわけではありませんが、同じスレッド内でキャンペーンが実行されるのをユーザが待機しないため、個々の要求に対する応答時間が短縮されます。
ただし、これには制限があります。同じ要求内でキャンペーンが必要な場合は、キャンペーンを非同期に設定しないことをお勧めします。
目標チェックを利用するキャンペーンを使用している場合は、目標チェックを適切に設定します。目標チェックは、キャンペーンの目標が達成されたかどうかを判断するために使用されます。開発者は
キャンペーンを作成するときに、キャンペーンが特定の日付に終了するように設定したり、目標セット (表示回数やクリック回数など) を使用したりできます。目標セットは、キャンペーンの継続期間に基づいて設定する必要があります。キャンペーンの目標チェック メカニズムの設定が低すぎると、ポータルのパフォーマンスに影響を及ぼします。デフォルトは 300000 ミリ秒 (5 分) です。
キャンペーンの目標チェック時間は、Administration Console を使用して調整できます。
この設定の調整方法の詳細については、『対話管理ガイド』の「
目標定義の調整」を参照してください。
キャンペーン サービスは、表示カウントを使用して、キャンペーンが最終目標に到達したかどうかを判断します。表示カウントは、広告プレースホルダがシナリオ アクションの結果として広告が表示されたことを検出するたびに、キャンペーン サービスによって更新されます。
デフォルトでは、キャンペーン サービスは、広告プレースホルダが 1 つまたは複数のシナリオ アクションの結果として 10 個の広告が表示されたことを検出するまで、データベース内の表示カウントを更新しません。パフォーマンスをチューニングするために、このデフォルトを変更して、キャンペーンのサポートに必要なデータベースのトラフィックを削減できます。
トラフィックが多いサイトでは、この数値を 50 ～ 100 に増やします。
広告サービス キャッシュをコンフィグレーションするには、Administration Console を使用して次の手順を実行します。
資格情報をキャッシュする場合は、キャッシュの設定を認識するようにアプリケーションをコンフィグレーションする必要があります。これは、netuix-config.xml ファイルを編集することで実行できます。
netuix-config.xml ファイルは、ポータル Web アプリケーションの WEB-INF ディレクトリにあります。
変更を加えた後、変更を有効にするには Web アプリケーションを再デプロイする必要があります。Web 記述子ファイルの変更の詳細については、『プロダクション業務ガイド』の「ポータル Web アプリケーションのデプロイメント記述子」を参照してください。
<entitlements control-resource-cache-size="200">
<enable>true</enable>
</entitlements>
ロール値は自動的にキャッシュされます。ただし、動的な属性 (セッションまたはリクエストの属性など) を使用する式でロールを定義すると、こうした式は実行時に評価されるので、キャッシュはほとんどまたはまったく不要になります。この場合、ロール キャッシングをオフにしてパフォーマンスを向上させます。
ロール キャッシングを無効にするには、個々のアプリケーションの web.xml ファイルを編集する必要があります。
| 注意 : | 変更を加えた後、変更を有効にするには Web アプリケーションを再デプロイする必要があります。Web 記述子ファイルの変更の詳細については、『プロダクション業務ガイド』の「ポータル Web アプリケーションのデプロイメント記述子」を参照してください。 |
web.xml ファイルに移動します。このファイルは、ポータル アプリケーション ディレクトリの WEB-INF サブディレクトリにあります。 web.xml ファイルをテキスト エディタで開きます。<env-entry> <env-entry-name>p13n.entitlements.disableRoleCache</env-entry-name> <env-entry-value>Y</env-entry-value> <env-entry-type>java.lang.String</env-entry-type> </env-entry> web.xml ファイルを保存します。
コンテンツ管理で検索機能を使用するときは、ノードの検索に使用する検索条件を指定できます。返されるノードの総数を減らすために、必ず検索クエリに重点を置きます。このためには、検索要求にクエリ条件を追加します。
コンテンツ検索機能を使用しない場合は、BEA リポジトリ コンフィグレーションで Autonomy と検索の両方を無効にしてこの機能をオフにします。Autonomy を無効にするには、サーバの起動時に WLP_SEARCH_OPTION=none 環境変数を設定します。コンテンツ リポジトリで検索を無効にする場合は、「検索の統合のガイド」を参照してください。
ページ付けでは、製品のパフォーマンス チューニング作業に重点の 1 つを置いています。結果セットに対してページ付けを実行する場合は、コンテンツ API によって提供されるオブジェクトの 1 つを使用します。
コンテンツ管理 API Javadoc で、さまざまなページング オプションを確認できます。
結果セットのバッチ サイズ (ノードの数) が大きいほど、全体的なパフォーマンスが向上します。可能であれば、返される結果セットのバッチ サイズを増やしてください。バッチ サイズがパフォーマンスに及ぼす影響の詳細については、『キャパシティ プランニング ガイド』を参照してください。
データベースのノードへのアクセス方法はいくつかありますが、ノードを取得する最も早い方法は、ノード ID を使用することです。可能であれば、この方法を使用してノードを取得してください。ノードへのさまざまなアクセス タイプがパフォーマンスに及ぼす影響の詳細については、『キャパシティ プランニング ガイド』を参照してください。
コンテンツ管理システムで BEA リポジトリを使用する場合、ポータル アプリケーションのニーズに基づいてキャッシュ設定をチューニングできます。パフォーマンスに関するその他の推奨事項とベンチマーク データは、BEA の
Dev2Dev Web サイトにあるホワイトペーパー「WebLogic Portal 9.2: Content Management Performance Optimization」、および『キャパシティ プランニング ガイド』で確認できます。
リポジトリ キャッシュを調整するには、『コンテンツ管理ガイド』に記載された
詳細リポジトリ プロパティを編集します。
ノードまたはバイナリのキャッシュ設定は、コンテンツへのアクセス頻度とキャッシュに保持するコンテンツの量に基づいて調整できます。割り当てたキャッシュ設定を処理できるだけのメモリがサーバに必要であることに注意してください。これらの設定は、アプリケーションの META-INF ディレクトリにある content-config.xml でコンフィグレーションされます。
PageFlow ポートレットを使用すると、サーバのメモリ使用量が大幅に増加する可能性があります。これは、各ポートレットがローカルでメモリを格納し、セッションでそのメモリを複製することが原因です。表示される各ポートレットは、ローカル メモリまたはセッションで 500 ～ 1000 バイトのデータを使用します。これは、アプリケーションにアクセスする各アクティブ セッションにも当てはまります。表示されるページ フロー ポートレットの数と、サーバ上のアクティブ セッションの数が多い場合、使用されるデータ量がすぐに増大する可能性があります。
ポートレットの requestAttrPersistence を transient-session 設定すると、セッションのデータ量を減らすことができます。ただし、このデータはシリアライズされるため、ローカル メモリ リソースがやはり消費されることになります。この詳細については、『ポータル開発ガイド』の「最適なパフォーマンスを得るためのポータルの設計」にある「ページ フロー セッションの占有量の最適化」を参照してください。
システムのこの潜在的な制限に対処するために、特定のポータルに表示されるページ フロー ポートレットの数を 100 未満にし、追加のオーバーヘッドを処理できるようにシステムのメモリを増やすことをお勧めします。
Web サービス リモート ポートレットのパフォーマンスに関するガイドラインの詳細については、『WebLogic Portal 連合ポータル ガイド』の「パフォーマンスの設計」を参照してください。
WSRP をチューニングするときは、プロデューサ マシンの数とコンシューマ マシンの数のバランスをとることが重要です。通常、WebLogic Portal は CPU にバインドされます。つまり、(通常はクラスタ化によって) 追加された CPU リソースを使用して、ボトルネックを解消できます。WSRP インフラストラクチャのパフォーマンス テストを実行することにより、プロデューサ マシンとコンシューマ マシンのどちらがボトルネックになっているかを判断し、必要に応じてリソースを追加することができます。コンフィグレーションおよびアプリケーションによっては、コンシューマまたはプロデューサのいずれかをクラスタ化することが必要になる場合があります。WSRP アーキテクチャの詳細については、『WebLogic Portal 連合ポータル ガイド』を参照してください。クラスタ化の詳細については、WebLogic Server ドキュメントの『WebLogic Server クラスタ ユーザーズ ガイド』を参照してください。
キャッシュはパフォーマンスに影響を及ぼしますが、(ポートレットの総数で決まる) ポータルのサイズが最も大きく影響します。WSRP ポートレットを使用する場合は、キャッシュを適宜調整してください。WSRP キャッシュの詳細については、『キャッシュ リファレンス』の「WSRP キャッシュ」を参照してください。
WebLogic Portal は、ポートレットを並列で表示する機能を備えています。これは、WSRP リモート ポートレットにも当てはまります。リモート ポートレットの表示に長時間かかっている場合、ポートレットの並列処理を有効にすることで、ポータル全体の表示速度が上がる場合があります。並列処理を有効にするには、ポートレットの forkPreRender 属性を使用します。『ポートレット開発ガイド』の「ポートレットの開発について」を参照してください。.
Weblogic Portal では、WebLogic Server の CommonJ WorkManager インフラストラクチャを使用して、フォークされたポートレットの事前表示および表示を行います。WorkManager のコンフィグレーション パラメータ、動作、およびデプロイメント オプションは似ていますが、まったく同じというわけではありません。8.1.4 以降のアプリケーションをアップグレードする場合、portalRenderQueue スレッド プールに対する既存のカスタマイズは、フォークに使用されるデフォルトのWorkManager に自動的には適用されません。
この WorkManager をチューニングするには、WorkManager をコンフィグレーションして、wm/portalRenderQueueWorkManager という名前を割り当てます。WebLogic Server 10.0 の WorkManager およびスレッドの使用方法の詳細については、WebLogic Server ドキュメントの「ワーク マネージャを使用したスケジューリング済み作業の最適化」を参照してください。
  
|
