|
|
ポータルのパフォーマンスの重要な側面は、ポータル アプリケーション レベルで管理されます。以下のものが含まれます。
WebLogic Portal には、キャッシュのコンフィグレーション、アクセス、モニタ、および管理に使用できる単一のフレームワークが用意されています。キャッシュを正しくコンフィグレーションすれば、頻繁に使用するデータの検索にかかる時間を大幅に短縮できます。キャッシュは読み込み専用であり、クラスタ対応であることに注意してください。
WebLogic Portal サービスの多くは、あらかじめコンフィグレーションされているキャッシュを使用しています。これらのキャッシュは、ユーザのパフォーマンスのニーズに合わせてチューニングできます。ただし、サービスによっては、ユーザがコンフィグレーションしたりアクセスしたりすることのできない、内部的にコンフィグレーションされたキャッシュを使用しているものもあります。サービスを拡張または追加する場合は、キャッシュ フレームワークを使用して独自のキャッシュ セットを定義し、使用することができます。
ポータル アプリケーションで使用可能なキャッシュのリストは、『キャッシュ リファレンス』に掲載されています。このリストをチューニングの際の補助として使用し、システムで使用可能なメモリを常に考慮するようにしてください。最大キャッシュ サイズを変更するときには、システム メモリもモニタして、その影響を判断します。
静的に定義されたキャッシュをコンフィグレーションするには、Portal Administration Console 内のサービス管理ツールを使用します。コンフィグレーション可能なキャッシュのリストは、『キャッシュ リファレンス』を参照してください。
キャッシュをコンフィグレーションするときは、パラメータを修正してキャッシュの動作または機能を変更します。各キャッシュには、最大サイズ設定と生存時間設定があります。たとえば、最新の 10,000 エントリのみ保持するようにキャッシュを設定し、キャッシュに残す時間を設定することができます。また、キャッシュをフラッシュして、情報に対するすべての新しい要求をデータベースから直接受け取ることもできます。
キャッシュ設定をコンフィグレーションする手順については、『キャッシュ リファレンス』の「キャッシュの追加」を参照してください。
一部の WebLogic Portal JSP タグは、セッションやページなどのさまざまなスコープでの結果のキャッシングをサポートします。これにより、個々のコンテンツ クエリのキャッシングをさらに詳細に管理できます。これは 1 つの利点とも考えられますが、キャッシュをコードで制御すると、アプリケーションのサイズ (コードの数) に応じて、キャッシュの変更にさらに多くのメンテナンスが必要になることを覚えておいてください。
たとえば、以下のコンテンツ管理に関連する JSP タグには、キャッシュ関連の属性が含まれます。
JSP タグおよびその属性の詳細については、「WebLogic Portal JavaDoc」を参照してください。
新しいポータル アプリケーションを作成すると、WebLogic Portal では、コマース サービス、イベント リスニング、キャンペーンなど、ほとんどのサービスが有効になります。これらのサービスがポータル アプリケーションで不要な場合は、サービスを無効にすることによって、パフォーマンスを向上させることができます。
行動追跡または個別のイベントを無効にすることができます。詳細については、『対話管理ガイド』を参照してください。
キャンペーンとは、強力なパーソナライゼーション用のツールです。これにより、きめ細かいルールに基づいて特定の Web コンテンツ、電子メール、および割引をユーザに向けて提供できます。次のヒントを利用してキャンペーン設定をチューニングすることで、パフォーマンスが向上します。
常にシナリオ ルールを特定のイベントに依存させます。それによって、シナリオ ルール内で参照されているイベント タイプに基づく最適化が可能です。
できる限り、余分なイベントを生成しないようにします。キャンペーン サービスは、すべてイベントをリスンする必要があります。イベントは、サイトで発生した重要なできごとを通知するために使用してください。
キャンペーンを非同期に設定すると、エンド ユーザがキャンペーンを表示する際の応答時間を早めることができます。これは AsynchronousEventListener メカニズムによって行います。
この最適化は、キャンペーンの結果を同じ要求内で必要としない場合に役立ちます。サーバに送られてくる次の要求 (必ずしも前の要求を行ったユーザからとは限りません) の前にキャンペーンが実行される場合は、キャンペーンを非同期に設定しているとキャンペーンのパフォーマンスが向上します。たとえば、ユーザがログインすると、キャンペーン コンテンツ プレースホルダは常にログイン フォームのすぐ後の画面に表示されるとは限らず、次のページ変更やページ更新の前に表示されることもあります。マルチスレッド アプリケーションの性質上、結果はすぐ次の画面に表示される可能性がありますが、必ずしもこれは保証されません。
キャンペーンを非同期に設定した場合、サーバの全体の負荷は減少しませんが、キャンペーンが同じスレッド内で実行されるのを待たないため各要求に対する応答時間が短くなります。
ただし、これには制限事項が 1 つあります。すなわち、キャンペーンが同じ要求内で必要な場合は、キャンペーンを非同期に設定することはお勧めしません。
目標チェックを利用するキャンペーンを使用している場合は、目標チェックを適切に設定してください。目標チェックは、キャンペーンが目標に達したかどうかを判断するために使用されます。開発者はキャンペーンを作成するときに、キャンペーンが特定の日付で終了するように設定したり、目標セット (表示回数やクリック回数など) を使用したりできます。目標セットは、キャンペーンの継続期間に応じて設定する必要があります。キャンペーンの目標チェック メカニズムの設定が低すぎると、ポータルのパフォーマンスに影響を及ぼします。デフォルトでは 300000 ミリ秒 (5 分) です。
キャンペーンの目標チェック時間は、Administration Portal を使用して調整できます。
設定の調整の詳細については、『対話管理ガイド』の「目標定義の調整」を参照してください。
キャンペーン サービスは、表示カウントを使用して、キャンペーンが最終目標に到達したかどうかを判断します。表示カウントは、広告プレースホルダにシナリオ アクションの結果として広告が表示されるたびに、キャンペーン サービスによって更新されます。
デフォルトでは、キャンペーン サービスは、広告プレースホルダが 1 つまたは複数のシナリオ アクションの結果として 10 個の広告が表示されたことを検出するまで、データベース内の表示カウントを更新しません。パフォーマンスをチューニングするために、このデフォルトを変更して、キャンペーンのサポートに必要なデータベースのトラフィックを削減できます。
トラフィックが多いサイトでは、この数値を 50 ～ 100 の範囲に増やします。
広告サービス キャッシュをコンフィグレーションするには、Administration Portal を使用して次の手順を実行します。
資格情報をキャッシュする場合は、キャッシュの設定を認識するようにアプリケーションをコンフィグレーションする必要があります。これは、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 アプリケーションのデプロイメント記述子」を参照してください。 |
<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>
コンテンツ管理システムで BEA リポジトリを使用する場合は、ポータル アプリケーションのニーズに合わせてキャッシュ設定をチューニングできます。その他のパフォーマンス推奨事項およびベンチマーク データは、BEAの dev2dev Web サイト上の『WebLogic Portal 9.2: Content Management Performance Optimization』ホワイトペーパーに記載されています。
リポジトリ キャッシュを調整するには、『コンテンツ管理ガイド』の「詳細リポジトリ プロパティの編集」を参照します。
ノードまたはバイナリのキャッシュ設定は、コンテンツのアクセス頻度とキャッシュ内に残すコンテンツの量に従って調整できます。割り当てたキャッシュ設定を処理するには、サーバに十分なメモリが必要であることに注意してください。この設定は、アプリケーションの META-INF ディレクトリ内にある content-config.xml でコンフィグレーションされます。
ページフロー ポートレットは、サーバ上のメモリ使用量を大幅に増加させる可能性があります。これは、各ポートレットが、メモリをローカルに格納するとともにセションにもレプリケートするためです。各表示ポートレットは、ローカル メモリまたはセッション内で 500 から 1000 バイトのデータを消費します。これは、アプリケーションにアクセスする各アクティブ セッションに当てはまります。サーバに表示ページフロー ポートレットが多数存在するか、アクティブなセッションが多数存在すると、消費量は一気に増加します。
ポートレットの requestAttrPersistence を transient-session に設定することで、セッション内のデータ量を減らすことができます。ただし、このデータはシリアライズされているため、この設定を行ってもローカルのメモリ リソースは消費されます。詳細については、『ポータル開発ガイド』の「最適なパフォーマンスを得るためのポータルの設計」にある「ページ フロー セッションの占有量の最適化」を参照してください。
このシステム制限事項に対処するために、各ポータル内で表示されるページフロー ポートレットの数を 100 より少なくし、さらに追加のオーバヘッドを処理できるようにシステム上のメモリを増やすことをお勧めします。
Web Services Remote Portlet に関するパフォーマンス ガイドラインの詳細については、『WebLogic Portal の連合ポータル ガイド』の「パフォーマンス用の設計」節を参照してください。
WSRP ポートレットを使用する場合は、キャッシュを適宜調整してください。WSRP キャッシュの詳細については、『キャッシュ リファレンス』の「WSRP キャッシュ」節を参照してください。
WebLogic Portal は WebLogic Server の CommonJ ワーク マネージャ インフラストラクチャを使用して、フォークされたポートレットの事前表示および表示を行います。ワーク マネージャのコンフィグレーション パラメータ、動作、およびデプロイメント オプションは似ていますが、同じではありません。8.1.4 以降のアプリケーションをアップグレードする場合、portalRenderQueue スレッド プールに対する既存のカスタマイズは、フォークに使用されるデフォルトのワーク マネージャに自動的に適用される訳ではありません。
このワーク マネージャをチューニングするには、ワーク マネージャをコンフィグレーションして、wm/portalRenderQueueWorkManager という名前を割り当てます。WebLogic Server 9.2 におけるワークマネージャおよびスレッドの使用の詳細については、WebLogic Server ドキュメントの「ワーク マネージャを使用したスケジューリング済み作業の最適化」を参照してください。
  
|
