最適なパフォーマンスを得るためのポータルの設計
|
 |
 |
|
パフォーマンスは、エンタープライズレベルのソフトウェア ソリューションを採用するときに必ず問題になります。WebLogic Portal も例外ではありません。ただし、パフォーマンスの問題の多くは製品の欠陥によるものではなく、アプリケーション開発の設計段階において決定を誤った結果です。適切なプランニングにより、WebLogic Portal の特長を利用して、ポータルの最適なパフォーマンスを実現することができます。
通常、ポータルのパフォーマンスは、訪問者が画面のオブジェクトをクリックしたとき (つまりポータル サーブレットにリクエストを送信したとき) に、ポータルとそのすべての構成要素が実際に表示されるまでにかかる時間で測定されます。さまざまな理由で、予期されるシステムの応答が悪影響を受けることがあります。いずれも適切な設計によって容易に対処および修正できますが、中でも最大の理由はポータルのレイアウトと設計です。
このドキュメントでは、いくつかの概念について説明し、高パフォーマンスのポータルを作成するためのヒントや実例を示します。このドキュメントは、次の節で構成されています。
ポータルのパフォーマンスに対する最大の障害は、ポータルのコントロールの数です。ポータルのコントロール (ページ、ポートレット、ボタンなど) が多くなると、コントロール ツリーが大きくなります。ポータルで使用可能なコントロールの詳細については、次の URL にある「ポータル コントロール」を参照してください。
http://edocs.beasys.co.jp/e-docs/wlp/docs81/whitepapers/netix/body.html#1061553
ポータルがインスタンス化されるときに、分類、すなわちポータル リソース (デスクトップ、ブック、ページ、ポートレットなど) の階層が生成されます。各リソースは、図 1 のようにコントロール ツリーのノードとして表されます。
この例では、1 つのポータルに 1 つのメイン ブックがあり、その中に 6 つのサブブックが含まれています。各サブブックにはそれぞれ 2 つのページがあり、各ページはそれぞれ 2 つのポートレットを含みます。これだけでも、このポータルのコントロールは少なくとも 42 になります。ボタン、ウィンドウ、メニュー、およびレイアウトを含めると、ポータルのコントロール数は大幅に増加します。
注意 : この例は、極めて単純化したものです。エンタープライズ ポータルに含まれるコントロールは数千に及ぶことがあります。
コントロール ツリーが構築され、すべてのインスタンス変数がコントロールに設定されたら、ポータル全体を表示する前に、ツリーが各コントロールのライフサイクルを実行する必要があります。ライフサイクル メソッドは、深さ優先順で呼び出されます。つまり、各コントロールの init() メソッドがすべて呼び出されてから、各コントロールの loadState() メソッドが呼び出されるというように続きます。順序は、ポータルの分類における各コントロールの位置によって決まります。たとえば、図 2 のコントロール ツリーに示される分類は、ブック (B1)、ブックに含まれる 2 つのページ (P1 および P2)、各ページに含まれる 2 つのポートレット (p1 ～ p4) で構成される単純なポータルです (p2 にはさらにサブブック、ページ、ポートレットの階層も含まれています)。
このポータルが表示されるとき、init() メソッド (_nfpb=true の場合は handlePostBackData() も) が各コントロールで最初に呼び出されます。順序は、B1、P1、p1、p2、B2、P3、p5、p6、P2、p3、p4 の順です。次に、loadState() メソッドが同じ順序で呼び出されます。同様に、saveState() まですべてのライフサイクル メソッドが呼び出されます。
注意 : コントロールのライフサイクル メソッド preRender()、render()、および dispose() は、表示されるコントロールのみで呼び出されます。
ライフサイクルを通して各コントロールを実行するには、オーバーヘッドの処理時間が必要になります。コントロールが数千に及ぶポータルであれば、処理時間も比例して長くなります。このように、ポータルのコントロール ツリーが大きくなると、パフォーマンスへの影響も増大することがわかります。
SP3 および以前のバージョンの WebLogic Portal でポータルの柔軟性を損なわずにコントロール ツリーのサイズを制限する最も単純な方法は、ポータルを複数のデスクトップに分割することです。ポータルの分類では、デスクトップは、別のポータルに埋め込まれたポータルとして扱われます。デスクトップは、ポータルに備わっているすべての機能を活用することができ、その中に別のデスクトップを含むことができます。
複雑なポータルを複数のデスクトップに分割すると、コントロールがそれぞれのデスクトップに分散されます。コントロール ツリーは個々のポータルに相当し、デスクトップはポータルと同様の動作をします。このため、各デスクトップが独自のツリーを持ち、そのツリーのコントロールはそのデスクトップが開かれたときにのみ構築されます。このように、大きなコントロール ツリーを持つ複雑なポータルを複数のデスクトップに分割することで、ツリーのコントロール数が、アクティブなデスクトップで必要な数にまで削減されます。つまり、ポータルを 1 つのデスクトップとして表示するために必要な時間が短縮し、ポータルのパフォーマンスが向上します。
ポータルが表示されるとき、処理時間の 15% はコントロール ツリーの構築に使用されます。ライフサイクル メソッドの実行には 70%、ガベージ コレクション (ヒープから不要なオブジェクトを消去して、新しいオブジェクトのために領域を解放するプロセス) には 15% が使用されます。構築とガベージ コレクションは常に実行されますが、ライフサイクル メソッドの実行は表示されるコントロール (デスクトップ上に見えているコントロール) についてのみです。したがって、複数のデスクトップの使用は、オーバーヘッドを大幅に節約し、システムのパフォーマンスの向上につながります。
たとえば、図 1 に示すコントロール ツリーの例は、42 のコントロールを含む 1 つのポータルを表します。このポータルを図 3 のように複数のデスクトップに分割した場合、ポータル全体でのコントロール ツリー数は増加しますが、各ツリーの大きさは約 3 分の 2 に縮小し、処理時間もおよそ 3 分の 2 になり、ポータルの表示に必要な時間が大幅に短縮されます。
図 4 は、図 3 の例を開いたときにどのように表示されるかを示します。
図 4 複数のデスクトップによるコントロール ツリー サイズの縮小
これらの例が示すように、複雑なポータルを複数のデスクトップに分割すると、パフォーマンスの向上の面では非常に効果的です。ただし、複数のデスクトップに分割する追加作業を考慮した場合、必ずしもすべてのポータルで有効な手段であるとは言えません。複数のデスクトップを使用してポータルを実装する前に、設計上の重要な決定事項について考慮する必要があります。以下に例を示します。
デスクトップの作成の詳細については、次の URL にある WebLogic Portal Administration Portal オンライン ヘルプ システムの「デスクトップを作成する」を参照してください。
http://edocs.beasys.co.jp/e-docs/wlp/docs81/adminportal/help/PM_DesktopCreate.html
WebLogic Portal 8.1 SP4 で、コントロール ツリーの最適化という概念が導入されました。ツリーの最適化とは、コントロール ツリーを表示するときに、システムのオーバーヘッドを最小限に抑えながらも、ユーザがポータル インスタンスを正常に使用するために必要なすべてのポータル コントロールを提供するようにすることです。
コントロール ツリーの最適化を有効にするには、コード リスト 1 に示すように、.portal ファイルの treeOptimizationEnabled フラグを true に設定します。
コード リスト 1 .portal でツリー最適化を有効にする
<desktop> element:
<netuix:desktop definitionLabel="defaultDesktopLabel"
markupName="desktop"treeOptimizationEnabled="true"markupType="Desktop" title="SimplePortal"><netuix:lookAndFeel
definitionLabel="defaultLookAndFeel">
<netuix:desktop/>
注意 : .portal ファイルに treeOptimizationEnabled= が含まれない場合、ポータルはデフォルトで treeOptimizationEnabled=false になります。
このフラグを "true" に設定すると、ポータル フレームワークによってコントロール ツリーの全体ではなく一部が生成されます。この部分的なツリーは、表示されてアクティブになるコントロールだけで構成されます。このように、表示する必要があるコントロールが減るため、処理時間とコストを大幅に削減できます。
図 5 WebLogic Workshop でツリー最適化を有効にする
図 6 Administration Portal でツリー最適化を有効にする
注意 : 新しいデスクトップのデフォルト値は treeOptimizationEnabled="true" です。この場合は何も設定する必要はありません。
フラグが実際に機能するためには、コード リスト 2 のように、ファイル url-template-config.xml (<PORTAL_HOME>/webAppName/WEB-INF にある) で <url-template> 要素に {url:currentPage} が設定されていることが必要です。
注意 : WebLogic Workshop で新しいプロジェクトを作成すると、currentPage が自動的に追加されます。ただし、以前のバージョンの WebLogic Portal から移行している場合は、url-template-config.xml を手動で更新する必要があります。
コード リスト 2 url-template-config.xml の URL テンプレート コンポーネント
<!-- URL templates -->
<url-template name="default">
{url:scheme}://{url:domain}:{url:port}/{url:path}?{url:queryString}
{url:currentPage}</url-template>
<url-template name="proxyurl">
{url:scheme}://{url:domain}:{url:port}/{url:prefix}/{url:path}?
{url:queryString}{url:currentPage}</url-template>
<url-template name="finurl">
https://fin.domain.com:7004/{url:prefix}/{url:path}?{url:queryString}
{url:currentPage}&dept=finance
</url-template>
<url-template name="default-complete">
{url:scheme}://{url:domain}:{url:port}/{url:prefix}/{url:path}?
{url:queryString}{url:currentPage}</url-template>
<url-template name="jpf-default">
http://{url:domain}:{url:port}/{url:path}?{url:queryString}
{url:currentPage}</url-template>
<url-template name="jpf-action">
http://{url:domain}:{url:port}/{url:path}?{url:queryString}
{url:currentPage}</url-template>
ポータル サーブレットはリクエスト (マウスのクリック) を受け取ると、キャッシュを読み取って、コントロール ツリー ファクトリが存在するかどうかを判断します。存在しない場合は、controlTreeFactoryBuilder を呼び出し、.portal ファイルから XML を渡します。このクラスがコントロール ツリー ファクトリをサーブレットに返し、サーブレットがリクエストを CreateUIControlTree クラスに渡します。
_pageLabel と treeOptimizationEnabled="true" が設定されている場合、CreateUIControlTreeFactory が PartialUIControlTreeCreator() メソッドを呼び出し、このメソッドは、指定のページ ラベルおよびアクティブなページとブックのラベルのセットで識別されるコントロールのみで構成されるコントロール ツリーを返します。これが、部分的なコントロール ツリーです。
たとえば、図 1 のポータルでツリー最適化が有効になっている場合、リクエストを発行する (マウスをクリックする) と、図 7 のようにアクティブなコントロールのみが表示されます。
図 7 ツリー最適化によるコントロール ツリー サイズの縮小
saveState() ライフサイクル メソッドの実行時に、このセッションでアクティブなページとブックのラベルのセットが格納されて、構築するコントロールが PartialUIControlTreeCreator() に通知されます。これらのコントロールのみが構築され、ポータルのそれ以外のコントロールは無視されます。結果として、コントロール ツリーを最適化すると、構築する必要のあるコントロールが減少するため、処理オーバーヘッドが大幅に削減され、パフォーマンスが大いに向上します。
WebLogic Portal 8.1 SP4 では、大量のコントロールを必要とする複雑なポータルを作成する場合に最適なポータル パフォーマンスを実現する最も簡単な方法は、ツリーを最適化することです。現在のポータル インスタンスでアクティブでないコントロールは構築されないので、時間とオーバヘッドが大幅に減少します。ただし、ツリー最適化によってポータルの動作が少し変化することや、ポータルの実装によってはツリー最適化を使用することが有効であるとは限らないことに注意してください。以下に例を示します。
DesktopBackingContext、BookBackingContext、および PageBackingContext では、次のメソッドがアクセスしようとしたページ、ブック、またはポートレットが部分的なツリーに含まれないと、null が返されます。public BookBackingContext getBookBackingContextRecursive(String definitionLabel)public PageBackingContext getPageBackingContextRecursive(String definitionLabel)public PortletBackingContext getPortletBackingContextRecursive(String instanceLabel)public PortletBackingContext[] getPortletsBackingContextRecursive(String definitionLabel)DesktopPresentationContext、BookPresentationContext、および PagePresentationContext でこれらのメソッドのプレゼンテーション バージョンを使用した場合も、同じ動作が発生することがあります。
public BookPresentationContext getBookPresentationContextRecursive(String definitionLabel)public PagePresentationContext getPagePresentationContextRecursive(String definitionLabel)public PortletPresentationContext getPortletPresentationContextRecursive(String instanceLabel)public PortletPresentationContext[] getPortletsPresentationContextRecursive(String definitionLabel)onDeactivation) を捕捉しようとした場合に問題になることがあります。ポートレットは非アクティブ化されると非表示になるので、システムがポートレットの非アクティブ化イベントを開始するためにポートレットを処理することはありません。推奨する解決策は、問題のポータルに対してツリー最適化を false に設定することです。ただし、ツリーの最適化が必要な場合は、裏技を使用できます。非アクティブ化イベントを捕捉したい各ポートレットについて、ダミーのイベント ハンドラを定義します (たとえば、event = "[任意の文字列]" を指定してカスタム イベント ハンドラを作成し、"Only If Displayed" プロパティを false に設定します)。これによって、ポートレットは非表示かどうかにかかわらず、システムで処理されます。 これらの条件に十分に注意し、必ず事前にポータルで完全なリグレッション テストを実行してから、treeOptimizationEnabled を true に設定してください。上記のいずれかの問題が発生した場合は、ポータルの設計を再考するか、ツリー最適化を完全に無効にする必要があります。
これまで説明したように、コントロール ツリーの最適化はほとんどのポータルに効果的ですが、場合によっては動作の制約があるために無効にする必要があります。最適化を無効にすると、リクエストのたびにポータルによってコントロール ツリー全体が作成されます。このとき大規模なポータルではパフォーマンスに大きな影響が出ることに注意してください。予期されるパフォーマンスの低下が、機能の向上で埋め合わせられるかを判断する必要があります。
.portal ファイルまたはデスクトップで treeOptimizationEnabled= "false" と設定する。nfto=false" を含める。URL はフレームワーク クラス GenericURL および PostbackURL を使用して生成されるため、パラメータを URL にプログラムによって追加する必要があります。これらのクラスの詳細については、WebLogic Portal の Javadoc を参照してください。 PostbackURL url = PostbackURL.createPostbackURL(request, response);
url.addParameter(GenericURL.TRE_OPTIMIZATION_PARAM, "false");
WebLogic Portal では、コントロール ツリーを効果的に使用してポータルの分類を管理する他にも、パフォーマンスを向上させる方法があります。これらのソリューションはすべて、複数のデスクトップやコントロール ツリーの最適化と組み合わせて使用でき、ポータルの優れたパフォーマンスを実現します。この節では、WebLogic Portal で提供される最も効果の高いパフォーマンス向上ソリューションについて説明します。
資格によって、ポータル アプリケーション内のリソースにどのユーザがアクセスできるか、そのリソースに対してユーザが何をできるかが決定されます。このアクセスはアプリケーションの訪問者に割り当てられているロールに基づいており、これによって柔軟なリソース管理が可能になります。たとえば、「従業員レビュー」というポートレットがある場合、「マネージャ」という訪問者の資格ロールを作成してポートレットに割り当てると、ログインしたユーザのうち、そのロールに属するユーザのみがポートレットを表示できます。
アプリケーションを訪問するユーザには、ユーザ名、ユーザが属するグループ、日時、またはユーザのプロファイルの特徴などを含む条件式に基づいて、ロールが割り当てられます。たとえば、マイレージ サービスの参加者で前年に 50,000 マイル以上搭乗したユーザに「ゴールド メンバー」ロールを割り当てることなどができます。このロールは、ユーザがサイトにログインしたときに動的に割り当てられます。
ポータルの最適なパフォーマンスを実現するためには、資格を慎重に使用する必要があります。資格が多すぎると、パフォーマンスに大きく影響します。資格エンジンは、処理の表示フェーズで呼び出され、システムのオーバーヘッドとルールをチェックする必要があるためです。このチェックによってさらにシステムのオーバーヘッドが増加するため、ポータルでチェックが頻繁に必要になると、パフォーマンスが影響を受けます。また、資格エンジンは管理タスクの管理も行うため、これによってもオーバーヘッドが増加し、パフォーマンスが低下します。
WebLogic Portal 8.1 Service Pack 4 以降のリリースでは、資格を LDAP ではなくデータベースに格納することにより、資格に関連するパフォーマンスが向上しています。その場合でも、資格が多すぎるとパフォーマンスの低下につながることに常に注意する必要があります。
資格を慎重に使用するための、簡単な推奨事項を以下に示します。
<control-resource-cache-size=nn> 属性の値を設定します。値には、ポータルで使用するデスクトップ数、ブック数、ページ数、ポートレット数、ボタン数 ([最大化]、[最小化]、[ヘルプ]、[編集] ボタン) の合計を指定します。使用可能なメモリ容量に懸念がある場合は、デフォルト値を使用します。http://edocs.beasys.co.jp/e-docs/wlp/docs81/perftune/4PortalApplication.html#1073678
ユーザ (訪問者) が変更できる対象を 1 ページまたは数ページのセットだけに制限し、残りのページは管理者が管理することをお勧めします。
ユーザがページをカスタマイズすると、ユーザはそのページのユーザ独自のインスタンスを取得します。カスタマイズされていない他のすべてのページは、元のライブラリ インスタンスを指します。管理者がページに変更を加えた場合、そのページをカスタマイズした各ユーザに対してその変更を繰り返し処理する必要があります。多くのユーザがそのページを変更した場合は、データベース処理が必要であるため、変更を伝播するのに時間がかかります。
レプリケートされたクラスタ環境では、ポータルでページ フロー ポートレットを使用すると、パフォーマンスの問題が発生することがあります。これらのポートレットに追加するリクエスト属性が、ページ フロー ポートレットの状態のコンポーネントとしてセッションに永続化されることがあるためです。追加するリクエスト属性が増えると、セッションのサイズが大きくなり、パフォーマンスが厳しく制約される可能性があります。
ページ フロー ポートレットは、ポータル フレームワーク内で、スコープ サーブレット環境によってホストされます。この環境は、サーブレット コンテナとして効果的に機能しますが、その動作のために、ページ フロー状態を永続化するコンテナ クラス内で、リクエスト属性のスコープがセッションに設定されます。これが特に望ましくないのは、大容量のデータ (このようなページ フロー ポートレットのリクエスト属性を含む) がクラスタ上でレプリケートされる場合です。
このような環境でパフォーマンスを向上させるために、WebLogic Portal 8.1 Service Pack 4 以降ではページ フロー ポートレットに requestAttrPersistence 属性が用意されています。requestAttrPersistence は .portlet ファイルに含まれており、WebLogic Workshop のプロパティ エディタで設定できます。
requestAttrPersistence には次の値があります。
session : 既存の動作です (デフォルト)。デフォルトでは、すべての既存のページ フロー ポートレットで変更の必要がありません。transient-session : 永続ページ フロー状態オブジェクトの、シリアライズ不可のラッパー クラスをセッションに挿入します。これらのポートレットの動作は、既存のポートレットと同じです。ただし、フェイルオーバの場合は例外です。永続リクエスト属性は、サーバへのフェイルオーバーが発生すると消失します。この場合、転送 JSP を作成してこのような不測の事態を適切に処理する必要があります。そのためには、少なくとも、特定のリクエスト属性が設定されていることを前提とせず、自動的にリクエスト属性を再設定するメカニズムを用意するか、最後のアクションを再実行してリクエスト属性を再設定するためのリンクをユーザに表示するのが理想的です。フェイルオーバがない場合、リクエスト属性は永続化され、非ポストバック ポートレットに対してデフォルトの session 永続性ポートレットに匹敵するパフォーマンスが実現されます。セッション メモリについては負荷が残りますが、永続リクエスト属性のための、追加のクラスタ レプリケーションの負荷は発生しません。none : 永続性操作を実行しません。このようなポートレットには、更新要求時に使用できるリクエスト属性がありません。そのため、リクエスト属性が使用できないことを前提に転送 JSP を作成する必要があります。このオプションは、フレームワークによって発生する、永続リクエスト属性のためのセッション メモリのロードを完全になくす場合に役立ちます。ページ フロー ポートレットについてリクエスト属性の永続性の属性を設定するには、図 8 のように、WebLogic Workshop のプロパティ エディタで [ページ フロー コンテンツ] グループの下の [リクエスト属性の永続性] ドロップダウンを開き、必要な値を選択します。
ポータルには、ファイルベースとストリーミングの 2 種類があります。ファイルベースのポータル (「ライト ポータル」とも呼ばれる) は、名前のとおりユーザのファイル システムからすべてのリソースを取得します。これに対して、ストリーミング ポータルは、リソースを 1 つ以上のデータベースから導出します。ファイルベース ポータルは開発時の使用を目的としていますが、静的ポータル (エンド ユーザや管理者のカスタマイズを必要としないポータル) またはごく単純なファイルを作成する場合は、プロダクション環境でもパフォーマンスが若干向上すると考えられます。
単純な静的ポータルでは、ファイル システムからリソースを導出するため、パフォーマンスが向上し、次の利点が得られます。
ファイルベース ポータルは、ストリーミング ポータルと比較してパフォーマンスが向上しますが、機能は限られます。たとえば、データベースを使用しないため、ユーザ カスタマイズや資格などの機能は利用できません。この他にファイルベース ポータルにない機能を以下に示します。
さらに、ほとんどのケースにおいて、ファイルベース ポータルの使用によるパフォーマンスの向上は、これらの制限の埋め合わせになるとはいえません。
この方法は実行時のパフォーマンス向上に直接はつながりませんが、アプリケーションをプロダクション環境に伝播する前にアプリケーションの実行の様子を確認することができます。開発時にプロダクション ドメインを作成することで、プロダクション環境でのポータルのパフォーマンスをシミュレートおよび評価できます。その後、必要な調整を行ってから、実際にポータルをデプロイすることができます。問題が発生する場合、またはパフォーマンスが最適ではない場合は、エンド ユーザに届く前にそのような状況を修正できます。
プロダクション ドメインを作成するには、起動スクリプトを更新します。WLS_PRODUCTION_MODE= フラグを true に設定し、次のフラグを false に設定します。
また、threadcount と JDBCConnectionPool のサイズにはデフォルト値を設定する必要があります。ポートレットをスレッド化 (forkable=true を使用) する場合、config.xml ファイルで portalRenderQueue や portalPreRenderQueue をコンフィグレーションし、フォークされたポートレットが WebLogic スレッド プールではなく独自のスレッド プールを使用するようにします。次のコード例は、スレッド数を適切に設定する方法を示します。
<ExecuteQueue Name="default" ThreadCount="15"/>
<ExecuteQueue Name="portalRenderQueue" ThreadCount="5"/>
<ExecuteQueue Name="portalPreRenderQueue" ThreadCount="5"/>
プロキシすなわち「リモート」ポートレットを実装すると、パフォーマンスが若干向上することがありますが、この方法にも制約が伴います。リモート ポートレットは、WSRP (Web Services for Remote Portlets) によって使用できるようになります。WSRP は、WebLogic Portal 8.1 Service Pack 3 から導入された Web サービス規格であり、これにより、ユーザ インタフェースを持つビジュアル Web サービスを、ポータルまたは他の仲介 Web アプリケーションと「プラグ アンド プレイ」することができます。これにより、エンタープライズから遠く離れた場所にあるアプリケーションでも WSRP 準拠プロデューサから実行して、ポータルにアプリケーションを表示することができます。
WSRP の使用の詳細については、次の URL にある「WebLogic Portal での WSRP の使用」を参照してください。
http://edocs.beasys.co.jp/e-docs/wlp/docs81/wsrp/index.html
リモート ポートレットを使用すると開発時間を短縮できますが (実際にポートレットのコンテンツを開発する必要がなく、コンテナのみを開発すればよいため)、パフォーマンスに関する主なメリットは、取得するアプリケーション (ポートレット) 内のすべてのコントロールがポータルではなくプロデューサによって表示されるという点です。コントロールのライフサイクル メソッドを呼び出すコストは、ポータルに関連しないリソースが負担します。
リモート ポートレットの使用によってポータルのパフォーマンスが向上しますが、デメリットもあります。以下に例を示します。
ポータルを表示するコストが転送のコストを上回り、上記のその他の制約がアプリケーションで特に重要でない場合は、リモート ポートレットによってポータルのパフォーマンスが向上します。
ポートレットの設定をカスタマイズすると、パフォーマンスの問題を回避することに役立つ場合があります。具体的には、以下のことができます。
表 1 は、WebLogic Workshop でポートレットを作成および変更するときに使用できる、パフォーマンス関連のポートレット プロパティを示しています。ポータル管理者がキャッシュ設定と表示オプションを調整できるようにポートレットが設計されている場合は、Administration Portal でこれらのプロパティを変更できます。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
バッキング ファイルを使用すると、Java クラスを実装 (または拡張) してポートレットにプログラミングによる機能を追加でき、ポータル コントロールを表示する前の事前処理 (認証など) が可能になります。バッキング ファイルは、WebLogic Workshop を使用するか、または .portlet ファイルにコードを直接入力することによって、ポータルに追加できます。
詳細については、『ポートレット間通信の確立』を参照してください。
ポートレットで大量のデータを表示する場合、特にそのデータが表内にある場合は、ページネーションの使用を検討してください。たとえば、Internet Explorer の表の表示方法では、大量のデータを処理する際にパフォーマンスが低下します。Internet Explorer やその他のブラウザで、適切な表示パフォーマンスでデータを表で表示するには、ページネーションを使用して、ポートレットが 1 度にすべてのデータを処理しなくて済むようにします。そうしない場合は、表を使用しないカスタム ルック アンド フィールの作成を検討してください。
これまで説明したように、WebLogic Portal における数多くのパフォーマンスの問題は、設計上の決定ミスが原因です。このドキュメントでは、次のような設計上のいくつかの重要な決定事項に注意すれば、非常に深刻なパフォーマンスの問題のうち、ポータルの表示に関するものは解決できること、また、パフォーマンスの大幅な向上が実現できることを説明してきました。
|
|
|
