|
|
可能な最大のパフォーマンスを得るためにポートレットを最適化するプロセスは、開発のすべての段階にまたがります。パフォーマンスを継続的にモニタし、適切な調整を行う必要があります。
この章では、ポートレットの開発時に組み込むことのできるパフォーマンスの最適化について説明します。
パフォーマンス関連のポートレット プロパティをカスタマイズすると、パフォーマンスが改善する場合があります。たとえば、プロセスが多いポートレットをマルチスレッド (フォーク可能) 環境で表示また事前表示されるように設定できます。ポートレットをフォーク可能である (マルチスレッド化される) と指定した場合、ポータルの構築時にその設定を調整できます。
以下のポートレット プロパティはパフォーマンスに関連するものです。
これらのプロパティについては、「ポートレット プロパティ」で説明します。ポータル管理者がキャッシュ設定と表示オプションを調整できるようにポートレットを設計している場合は、Administration Console でこれらのプロパティを変更できます。
セッション中に (別のページなどで) 再利用されるたびにポートレットを取得するのではなく、セッション内でポートレットをキャッシュできます。Web サービスを呼び出すポートレットは、コストのかかるプロセスを頻繁に実行します。Web サービス ポートレットをキャッシュすると、パフォーマンスが向上します。ポートレットのキャッシュは、パーソナライズされたコンテンツのキャッシュに適しています。対照的に、すべてのユーザに同じ状態で表示され、期限切れがほとんど発生しない静的コンテンツのキャッシュには適していません。
ポートレット キャッシュは、各ユーザ向けにパーソナライズされた、頻繁に期限切れになるコンテンツで使用するのが理想的です。他の状況では、wl:cache タグまたはポータル キャッシュなどの代替キャッシュ方法の使用が適している場合があります。
[表示キャッシュ可能] プロパティの詳細および適切な使用方法については、dev2dev の記事「ポートレットのキャッシング」(筆者 : Gerald Nunn) を参照してください。この記事は、http://www.beasys.co.jp/dev2dev/products/wlportal81/articles/portlet_caching.html で閲覧できます。
リモート ポートレットは、WSRP (Web Services for Remote Portlets) によって使用できるようになります。WSRP は Web サービス規格で、これにより、ポータルまたは他の仲介 Web アプリケーションと、ユーザ インタフェースを持つビジュアルな Web アプリケーションを「プラグ アンド プレイ」することができます。WSRP により、エンタープライズから遠く離れた場所にあるアプリケーションでも WSRP 準拠プロデューサから実行して、ポータルにアプリケーションを表示することができます。
リモート ポートレットによってパフォーマンスが改善することはありますが、パフォーマンス改善はリモート ポートレット実装の主な理由ではありません。リモート ポートレットのパフォーマンスに関する主な利点は、取得するアプリケーション (ポートレット) 内のすべてのポータル フレームワーク コントロールが、ポータルではなくプロデューサによって表示されるという点です。コントロールのライフサイクル メソッドを呼び出すコストは、ポータルに関連しないリソースが負担します。
リモート ポートレットを使用する実装には、以下の制限があります。
ポータルを表示するコストが転送のコストを上回り、上記のその他の制約がアプリケーションで特に重要でない場合は、リモート ポートレットによってポータルのパフォーマンスが向上します。
WSRP を使用したリモート ポートレットの実装の詳細については、『連合ポータル ガイド』を参照してください。
プロセスが多いポートレットをマルチスレッド (フォーク可能) 環境で表示するように設定できます。ポートレットをフォーク可能である (マルチスレッド化される) と指定した場合、ポータルの構築時にその設定を調整できます。これにより、ポートレットを順次ではなく、ページ上の他のポートレットと同時に (つまり、並列して) 表示できます。結果としてポータル リクエスト (ポータル ページ) をユーザに表示する全体的な応答時間が短縮されます。
WebLogic Portal では、フォーク (事前表示または表示) とはサーバ上で行われるページ処理を意味します。各ポートレットを処理するために複数のスレッドが生成されます。対照的に、ポートレット コンテンツの非同期表示とは、クライアント ブラウザで発生するページ処理を意味します。AJAX または IFRAME テクノロジを使用して複数のスレッドが生成されます。
以下の節では、事前表示および表示フォークの実装方法を説明します。
| 注意 : | ポートレットの非同期表示のスレッドの安全性に関する考慮事項は、ポートレットの並列表示についても該当します。詳細については、「スレッドの安全性と非同期表示」を参照してください。 |
[フォーク事前表示] 属性を設定すると、ライフサイクルの事前表示段階でフォーク (マルチスレッド) が有効になります (コントロール ツリーのライフサイクルの詳細については、『ポータル開発ガイド』の「コントロール ツリーのパフォーマンスへの影響」を参照)。[フォーク事前表示] 属性を true に設定すると、ポートレットの事前表示段階がフォークされます。表示段階のフォークと同様に、ポートレットの [フォーク可能] 属性が true に設定されている場合のみ、事前表示段階をフォークすることができます。
この機能を使用すると、ほとんどの状況でユーザに対する応答時間が短縮されます。ただし、負荷が高いシステムではサーバ/JVM で各リクエストに使用されるスレッド数が増加して、共有リソースの競合が増加するため、全体的なスループットが低下する場合があります。
事前表示フォークは、以下のポートレット タイプによってサポートされる。
各ポートレット タイプで事前表示フォークを有効にするには、プロパティ ビューで以下のポートレット プロパティを編集します。
各プロパティの説明については、表 5-7 を参照してください。
ポートレット コンテンツの非同期表示でフォーク事前表示を使用する必要はありません。予期しない動作が発生する可能性があるため、使用は推奨されません。
[フォーク表示] 属性を設定すると、ライフサイクルの表示段階でフォーク (マルチスレッド) が有効になります。[フォーク表示] 属性を true に設定すると、ポートレットの表示段階がフォークされます。事前表示段階のフォークと同様に、ポートレットの [フォーク可能] 属性が true に設定されている場合のみ、表示段階をフォークすることができます。
| 注意 : | 表示フォークの使用状況に関係なく、すべてのポートレットの表示が完了するまで、ポータルは表示を行いません。ポートレットを個別に表示させたい場合、ポートレットの非同期表示を使用します。詳細については、「ポートレット コンテンツの非同期表示」を参照してください。 |
| 注意 : | 表示フォークを使用する場合、サーバから返される HTML はフォーク表示を使用しない場合とまったく同じ状態です。ポートレット コンテンツの非同期表示では動作が大幅に異なります。詳細については、以下を参照してください。 |
表示フォークは、以下のポートレット タイプによってサポートされます。
各ポートレット タイプで表示フォークを有効にするには、プロパティ ビューで以下のポートレット プロパティを編集します。
各プロパティの説明については、表 5-7 を参照してください。
ポートレット コンテンツの非同期表示でフォーク表示を使用する必要はありません。予期しない動作が発生する可能性があるため、使用は推奨されません。
ポートレットの非同期表示によって、周りのポータル ページから独立してポートレットのコンテンツを表示できます。これにより、パフォーマンスが大幅に改善される可能性があります。たとえば、ポータルの訪問者がポートレット内で作業する際に、その個別のポートレットのみを再表示します。
| ヒント : | ポータルデスクトップ全体に対する非同期表示を有効にすることもできます。ポートレット固有 （この節で説明) とデスクトップ非同期表示のどちらでも､応答時間が同期表示よりも速くなります｡ポートレット固有と非同期表示用デスクトップ オプションは､相互排他的な機能であることに注意してください｡非同期デスクトップ表示と方法を選択する際のヒントについては、『WebLogic Portal 開発ガイド』の「最適なパフォーマンスを得るためのポータルの設計」を参照してください。 |
AJAX テクノロジまたは IFRAME テクノロジを使用して個々のポートレットの非同期表示を実装できます。ポートレットの非同期表示を使用すると、ポートレットは 2 つの段階で表示されます。まず、通常のポータル ページ リクエスト処理が行われ、この処理中にタイトル バーなどコンテンツ以外の領域が表示されます。実際のポートレット コンテンツではなく、コンテンツのプレースホルダが表示されます。続けて行われるリクエスト処理で、ポートレットのコンテンツが表示されます。
プロパティ ビューのポートレット プロパティ asyncContent により、非同期表示の有無および使用するテクノロジを指定できます。編集可能なドロップダウン メニューでは、none、ajax、または iframe を選択できます。非同期表示のカスタマイズされた実装を作成する場合は、.portlet ファイルを編集します。このタスクは、将来的に dev2dev の記事で詳しく説明します。
asyncContent 属性を含まないポートレット ファイルは、プロパティ ビューで初期値 none が表示されます。設定の変更内容は .portlet ファイルに保存されます。
| 注意 : | ブラウザ ポートレットは、非同期ポートレットと同様の内部実装を使用します。また、いずれのポートレット タイプも IFRAME HTML 要素を使用しますが、実際の実装は大幅に異なります。ブラウザ ポートレットは静的な埋め込み文書を表示しますが、非同期 IFRAME ポートレットはフレームワークにより管理されます。 |
非同期表示の実装では、以下の全体的な考慮事項に留意してください。
ブラウザがナビゲーションを処理する場合、ポートレットの動作は使用する非同期表示テクノロジによって異なるため、エンド ユーザを混乱させる可能性があります。たとえば、IFRAME テクノロジでは各ポートレットの対話が追跡されますが、この対話はサーバ パースペクティブからの「ビュー」を更新しません。ユーザが [戻る] ボタンをクリックした場合、サーバはポートレットとの対話を行う前の状態にユーザを戻してしまいます。
com.bea.netuix.servlets.controls.portlet.PortletPresentationContext.isAsyncContent()
com.bea.netuix.servlets.controls.portlet.PortletPresentationContext.isContentOnly()
com.bea.netuix.servlets.controls.portlet.backing.PortletBackingContext.isAsyncContent()
com.bea.netuix.servlets.controls.portlet.backing.PortletBackingContext.isContentOnly()
ポートレット コンテンツの非同期表示を使用する場合、バッキング ファイルなどのコードがスレッド セーフであることを確認してください。ポータル フレームワークは、リクエストと応答への同時アクセスなど、開発者が制御できない主要な問題に対処します。また、非同期操作がすべて完了するまで待機して結果を正しい順番に並べ替えるなど、問題の調整も管理します。ただしポートレット開発者は、ユーザ コードがスレッド セーフであることを確認する必要があります。
この考慮事項は、並列 (フォーク) ポートレット処理にも該当します。
IFRAME ベースの非同期表示に特有の考慮事項を以下に示します。
<render:context> タグまたは AsyncContentContext クラスを使用すると、特定の操作について非同期表示を無効にできる。ただし、IFRAME ベースの非同期表示を使用している場合は、これらのメカニズムは正しく機能しない。この問題を回避するには、非同期表示を無効にするか、または AJAX ベースの非同期表示を使用する。
非同期 JavaScript および XML (AJAX) ベースの非同期表示に特有の考慮事項を以下に示します。
表 6-1 に、IFRAME および AJAX ベースの非同期表示の長所と短所をまとめます。堅牢性の高い実装としては AJAX をお勧めします。
以下の表では、通常またはフォーク表示と、ポートレット コンテンツの非同期表示の動作および機能を比較しています。
この節では、コンテンツの非同期表示の使用に関連するライフサイクルおよびコントロール ツリーの影響について説明します。
ポータル ページの初期リクエストでは、ポートレットに追加されたバッキング ファイルは、完全なポータル コントロール ツリーのコンテキストで実行されます。ただし、ページ フロー、管理対象 Bean、JSP ページなどのポートレット コンテンツは、初期リクエストでは実行されません。
PortletBackingContext.isAsyncContent() = true
PortletBackingContext.isContentOnly() = false
続けて行われるコンテンツ リクエストでは、ポートレットに追加されたバッキング ファイル、およびページ フロー、管理対象 Bean、JSP ページなどのポートレット コンテンツが「ダミー」のコントロール ツリーのコンテキストで実行されます。
PortletBackingContext.isAsyncContent() = true
PortletBackingContext.isContentOnly() = true
PortletPresentationContext.isAsyncContent() = true
PortletPresentationContext.isContentOnly() = true
このモデルの重要な結果として、ポートレットでコンテンツの非同期表示を有効にすると、ポートレット コンテンツはポータルの他の部分と分離されて実行されます。つまりこのようなポートレットは、ブック、ページ、デスクトップ、他のポートレットなど他のポータル コントロールに直接アクセスできません。
コンテンツの非同期表示が有効な場合は IPC はサポートされませんが、WebLogic Portal には、ポータル環境でのこれらの 2 つのメカニズムの共存を許可するいくつかの機能があります。また、この節で説明するメカニズムを使用して、単一のリクエストの非同期表示を無効にできます。
| 注意 : | この節で説明する方法は、現在 IFRAME ポートレットで使用できません。 |
| ヒント : | 非同期表示をポータル/デスクトップ レベルで有効にする場合、制限なしで IPC を使用できます。非同期ポータル/デスクトップ表示の詳細については、『WebLogic のポータル開発ガイド』を参照してください。 |
ファイル アップロード メカニズムを含むフォームの場合、WebLogic Portal フレームワークは解決策をまったく使用せずに自動的にページ更新を行います。
一般的に、ポートレットが単一の対話 (たとえば、フォーム送信、リンク クリックなど) のためにコンテンツの非同期表示を無効にしなければならない場合は、この節で説明するメカニズムを使用してください。
| ヒント : | これらのメカニズムを使用して非同期表示を無効にすると、ポートレットのアクション/表示は 2 つのリクエストを使用して実行されます。ポートレットのアクションはページ リクエストで実行される一方、ポートレットの表示は以降のリクエストで実行されます。アクションがリクエスト属性を使用しないで情報を JSP ページに渡すことを確認してください。 |
<render:controlContext asyncContentDisabled="true">
フォームやアンカなどがここに挿入されます
(つまり、<netui:form action="submit"...)
AsyncContentContext.push(request).setAsyncContentDisabled(true);
AsyncContentContext.pop(request)
URL 圧縮は、AJAX 固有の一部のページ更新メカニズムを妨げます。このため、ページ更新を強制的に行うためにコンテンツの非同期表示を無効にした場合は、URL 圧縮も無効にする必要があります。WebLogic Portal では、ファイルのアップロード フォームが使用される場合を除き、URL 圧縮が自動的に無効になります。その場合は、URL 圧縮を明示的に無効にする必要があります。次の例をガイドとして使用できます。
<render:controlContext urlCompressionDisabled="true">
フォームやアンカなどがここに挿入されます
(つまり、<netui:form action="submit"...)
UrlCompressionContext.push(request).setUrlCompressionDisabled(true);
UrlCompressionContext.pop(request)
URL 圧縮の実装方法の詳細については、『ポータル開発ガイド』を参照してください。
  
|
