| Oracle® Fusion Middleware Oracle WebCenter Sitesでの開発 12c (12.2.1.1) E77292-01 |
|
 前 |
 次 |
ページ・キャッシングの高度な手法の詳細は、次の項を参照してください。
キャッシングにより、ページの処理速度が上がります。レンダリングされたコンテンツをキャッシュすることにより、コンテンツが要求されるたびにレンダリングする必要がなくなります。これにより、レスポンス時間が短縮されます。
キャッシング・システムには、複数のレイヤーがあります。これにより、キャッシュされたオブジェクトを1つのキャッシュ・レベルで再生成でき、その一方で、別のキャッシュ・レベルにキャッシュされたコンテンツがクライアントに提供されます。WebCenter Sitesは内部レベルのキャッシュであり、Satellite Serverは外部レイヤーのキャッシュです。
WebCenter SitesとSatellite Serverでは両方とも、ページ、ページレットおよびBLOBがキャッシュされます。WebCenter Sitesには、CSページ・キャッシュ、BlobServerキャッシュ、SSキャッシュという3種類のレンダリング・エンジン・キャッシュが用意されています。すべてのキャッシュを次のように構成したり、空にしたりできます。
WebCenter Sitesキャッシュ、BlobServerキャッシュおよびSatellite Serverキャッシュの最大キャッシュ・サイズの構成の詳細は、「キャッシュの最大サイズの構成」を参照してください。
WebCenter SitesキャッシュおよびBlobServerキャッシュの有効期限の設定の詳細は、「個々のエントリの有効期限の設定」を参照してください。
WebCenter Sitesキャッシュ、BlobServerキャッシュおよびSatellite Serverキャッシュのキャッシュからのオブジェクトの削除の詳細は、「キャッシュからのエントリの明示的削除」を参照してください。
WebCenter Sitesページ・キャッシュには、2つのレベルのキャッシングがあります。
データベース内。
メモリー内。メモリー・キャッシュは、データベース・キャッシュの透過的なサブセットですが、単独での構成が可能です。
この項には次のトピックが含まれます:
WebCenter Sitesのデータベース・キャッシュには、最大サイズ構成オプションはありません。ページ・キャッシュのメモリー・サブセットを使用すると、存在するエントリの最大数を指定できます。
wcs_properties.jsonファイル内のcc.SystemPageCacheCSzプロパティに正の整数を設定し、キャッシュ内に存在できるエントリの最大数を指定します。
注意:
値を0に設定すると、すべてのエントリが追加され、即座に削除されます。ただし、これは避ける必要があります。
cc.SystemPageCacheCSzプロパティは-1に設定しないでください。
キャッシュでは、最低使用頻度(LRU)アルゴリズムを使用して、最大数に達したときにプルーニングするエントリを識別します。
最大サイズには、キャッシュに格納される総バイト数は反映されません。
ページ・キャッシュ内のエントリのライフタイムは、cscacheinfo設定により決定されます。CacheInfoオブジェクトは、cscacheinfoフィールドに明示的に設定されていない値を構成ファイルから取得します。CacheInfoの構文については、「CacheInfo文字列の構文」を参照してください。
WebCenter Sitesには、キャッシュからエントリを削除する方法が2つ用意されています。1つは手動、もう1つはCacheManagerを使用した自動的な方法です。
CacheServerサーブレットを使用して、ページ・キャッシュからエントリを手動で削除できます。CacheServerには、次の2つのオプションが用意されています。
キャッシュ全体をフラッシュします。
有効期限が切れた時点で、すべてのページのフラッシュを強制します。CacheServerのすべてフラッシュする機能を起動するためには、SiteCatalog表を破棄する権限を持つユーザーとしてログインし、CacheServerサーブレットの起動時にパラメータall=trueを指定する必要があります。パラメータを指定しないと、有効期限が切れたエントリ(有効期限が過去であるエントリ)がすべて、キャッシュからただちにクリアされます。有効期限がまだ切れていないエントリはクリアされません。
注意:
有効期限が切れたエントリは、たとえまだデータベース表の中にあったとしても、キャッシュから提供されることはありません。WebCenter Sitesでは、ページを表示する前に、キャッシュから取得されたすべてのページの有効期限がチェックされます。有効期限が切れたページをWebCenter Sitesが表示しようとすると、そのページはただちにキャッシュから削除され、新しいページが生成されます。
CacheManagerは、WebCenter SitesのページおよびBLOBのキャッシュ・メカニズムと密接に結び付いているモジュールです。これにより、ページにロードされたアイテム、ページの有効期限、またはページに渡されるパラメータに基づいて、すべてのレンダリング・キャッシュのコンテンツを管理できるようになります。
CacheManagerのみが、完全に独立したドキュメントの対象になる場合もあります。その機能の概要はここで説明します。メソッドおよび必要な引数の詳細は、COM.FutureTense.Cache.CacheManager Javadocを参照してください。
これらのメソッドを使用すると、パフォーマンスがきわめて高い動的サイトを可能にするツールである、二重バッファ・キャッシングを利用できます。二重バッファ・キャッシングの詳細は、「ページのデザインとキャッシングの理解」を参照してください。
BlobServerキャッシュは、オール・オア・ナッシングのキャッシュです。つまり、エントリはグローバルにキャッシュされるか、グローバルにキャッシュされないかのどちらかです。
セキュリティが有効な場合、またはbs.security=trueである場合、BlobServerキャッシングが無効になります。
この項には次のトピックが含まれます:
WebCenter Sitesのwcs_properties.jsonファイル内のbs.bCacheSizeプロパティは、BLOBキャッシュに含まれるエントリの数を指定します。サイズに負の数が設定されると、BLOBキャッシュを無制限に増大することが許可されます。
BlobServerは、キャッシュされたエントリの有効期限をサポートしていません。キャッシュされたオブジェクトはすべて、WebCenter Sitesのwcs_properties.jsonファイル内のbs.bCacheTimeoutプロパティで決められたタイムアウトの期間、キャッシュ内に存在します。負のタイムアウト値は、エントリがタイムアウトしないことを示します。正の整数は、オブジェクトがキャッシュ内に存在する期間(単位は分)を指定します。
BlobServerを使用すると、個々のエントリまたはすべてのエントリをキャッシュからフラッシュできます。
キャッシュからエントリを手動で削除するには、blobtableパラメータの名前をflushblobtableに変更します。これにより、残りのパラメータに対応するエントリがキャッシュから削除されます。
キャッシュからすべてのエントリを手動で削除するには、2つのオプションがあります。
パラメータflushblobtables (sに注意)でBlobServerサーブレットを起動します。
前述のようにCacheServerサーブレットを起動します。この場合、すべてのページとすべてのBLOBがキャッシュからフラッシュされることに注意してください。
BLOB依存アイテムはBLOBリンクが生成されたときに記録されるため、BLOBおよびページを管理するためにCacheManagerを起動できます。CacheManagerは常にBLOBとページを一緒に管理します。詳細は、「CacheManager」、「CacheManagerについて」および「CacheManagerの有効化」を参照してください。
注意:
BLOBを提供する前に、開発者はアセットのステータスをチェックする必要があります。これにより、アセットが無効化された後に、BlobServerによってBLOBが提供されるという問題を回避できます(この動作は、ベーシック・アセットでのみ発生します)。
汎用的なSatellite Serverキャッシュ構成は、wcs_properties.jsonファイル内で行われます。ただし、キャッシュ構成は多くの場合、オブジェクト単位でオーバーライドされます。
wcs_properties.jsonファイル内のcache_maxプロパティを、キャッシュ内に一度に格納できるエントリの最大数に更新します。
このプロパティに負の整数を設定すると、キャッシュのサイズは制限されません。正の整数は、キャッシュに格納できるエントリの最大数を指定します。
この項で説明しているように、個々のエントリは、手動で、またはCacheManagerを使用して、Satellite Serverキャッシュから削除できます。
手動削除: Satellite Serverには、FlushServerと呼ばれるサーブレットがあります。(username、password、resetの各パラメータを指定して)このサーブレットにGETリクエストを送信することにより、Satellite Serverキャッシュのコンテンツのすべてをフラッシュできます。GETを使用して個々のエントリはフラッシュできません。
自動削除: CacheManagerを使用してSatellite Serverキャッシュをフラッシュできます。対応するオブジェクトがWebCenter Sitesにキャッシュされた場合、CacheManagerはSatellite Serverのエントリのみをフラッシュすることができます。これは、WebCenter SitesがSatellite Serverキャッシュのコンテンツを追跡する方法によるものです。
CacheManagerを使用してSatellite Serverキャッシュがフラッシュされる場合、対応するオブジェクトがWebCenter Sitesにキャッシュされます。対応するオブジェクトが必要となるのは、WebCenter SitesがSatellite Serverキャッシュのコンテンツを追跡する方法によるものです。
Satellite Serverキャッシュを処理するための該当するCacheManagerメソッドは、flushSSEngines()およびrefreshSSEngines()です。メソッドの詳細は、「キャッシュからのエントリの明示的削除」を参照してください。
SiteCatalogのcscacheinfoフィールドおよびsscacheinfoフィールドには、CacheInfo文字列が移入されます。この項では、2つの部分で構成されたカンマ区切り文字列のフォーマットにより、ページをキャッシュするかどうか、およびページがいつ期限切れになるかを決定する方法について説明します。
サンプル値は次のとおりです。
false true true,* true,~4 true,@1987-06-05 04:32:10 true,#00:00:00 */*/* * (blank)
CacheInfo文字列: 最初の部分
CacheInfoの最初の部分は、次の値のいずれかである必要があります。
false true (blank)*
値がfalseの場合、ページはキャッシュされません。
値がtrueの場合、2番目のエレメントに指定された情報に従って、ページがキャッシュされます。
値が空白の場合、wcs_properties.jsonのcs.alwaysusediskプロパティがチェックされます。このプロパティがyesに設定されている場合、空白値はtrueと同じ動作をするものと解釈されます。この値がno (デフォルト値)に設定されている場合、空白値はfalseと同じ動作をするものと解釈されます。
値が*の場合、これは空白として処理されます。
CacheInfo文字列: 2番目の部分
これは、キャッシュされるページをキャッシュからいつ削除するかを記述します。最初のエレメントがfalseの場合(またはfalseと解釈される場合)、2番目のエレメントは無視されます。
ページの有効期限を指定する方法には、次の3つがあります。
page timeout (in minutes)
instant in time expiration
cron-like TimePattern expiration
使用可能な値は次のとおりです。
~<number of minutes> @<date in JDBC format> #<COM.FutureTense.Util.TimePattern format> * (blank)
ページ・タイムアウト
2番目のエレメントがチルダ(~)で始まる場合、続く値は整数である必要があります。この整数の値は、ページが最初に作成されてからキャッシュ内に残る期間(単位は分)です。負の値または0は、ページの有効期限が切れない(ページが永久にキャッシュ内に残る)ことを示します。
絶対時間
2番目のエレメントがアット記号(@)で始まる場合、続く値はJDBC日付文字列フォーマット、つまりYYYY-MM-DD HH:MM:SSのフォーマットで表現される日付である必要があります。その日付が過ぎると、キャッシュされたページはキャッシュからフラッシュされ、そのページはキャッシュされていない状態になります。
TimePattern
TimePatternフォーマットは、ページ・キャッシュの有効期限の記述のためにサポートされています。2番目のエレメントがハッシュタグ(#)で始まる場合、続く値は、パブリック・クラスCOM.FutureTense.Util.TimePatternで定義された有効なTimePattern文字列である必要があります。
一般的に、TimePattern構文は、ほとんどのUNIX cron表で使用されるフォーマットに対応しています。これにより、特定の時間または毎日、毎月、毎週、毎曜日および毎年で、有効期限を指定できます。
TimePatternフォーマットは、ページ有効期限のために最も広く使用されるフォーマットになると考えられています。
ワイルドカード
2番目のエレメントが*である場合、「ページ・タイムアウト」で記述したように、ページはタイムアウトによる有効期限切れの動作になります。タイムアウト値は、wcs_properties.jsonファイルのcs.pgCacheTimeoutプロパティから読み込まれます。
空白
2番目のエレメントが空白の場合、*と同じ動作が適用されます。
WebCenter SitesのWebページには、リモートSatellite Serverによって処理されるキャッシュ済プライマリ・ページレットが最大で6から10含まれることが理想的です。これは、キャッシュ済ページレットが多すぎると、キャッシュの容量オーバーになり、システムのパフォーマンスに悪影響を及ぼすからです。
次の項では、キャッシュの容量オーバーを阻止し、レスポンス時間とスループットを向上させる方法について説明します。
ページ当たりの未キャッシュ・ページレットの数が少なくなるようにページ・テンプレートを設計します。<render:calltemplate>タグのデフォルトのstyle=pageletが常に最善の選択肢であるとはかぎりません。ページ当たりのページレットの数を削減すると、レスポンス時間とスループットが向上します。
すでにページ・テンプレートがあり、これらの再設計が実現可能でない場合は、リモートSatellite Serverから、共存しているSatellite Serverに切り替えます。WebCenter Sitesサーブレットと、共存しているSatellite Serverの間のラウンドトリップは必要ありません。ページ上に存在する未キャッシュ・ページレットの数が多いほど、共存しているSatelliteServerの方がリモートSatellite Serverよりレスポンス時間が向上する可能性が高くなります。
キャッシュ済ページレットを結合してこれらの数を削減します。最初に、各<render:calltemplate>コールでpageletのデフォルトのスタイル属性値を使用しているかどうかをチェックします。<render:calltemplate>コールをエレメント・コールとしてインライン化(style=element)することにより、ページレットの数を削減します。
style="element"を指定する場合の一般的なユースケースは、外部のコール元のテンプレート(ページまたはページレット)が内部のコール先のページレット・テンプレートと同じc、cidを共有する場合です。キャッシュ済オブジェクトは両方とも同時に期限切れになる(つまり、これらのアセットの依存性は同じである)ため、これらを個別にキャッシュするメリットはありません。
サブページレットをリモートSatellite Server上で直接キャッシュするかわりに、style="embedded"バリアントを使用してContentServerサーブレット上でページレット・キャッシュを介してサブページレットをバックアップします。つまり、<render:calltemplate>コールをContentServerページ・フラグメントとしてインライン化(style=embedded)します。
たとえば、Webページ内の製品サマリーのリストに10のアイテムが含まれる場合、これは、これらの各アイテムにデフォルトのstyle="pagelet"が適用されることを意味します。ページレットのスタイルが原因で、このリストをレンダリングするためにWebCenter SitesサーブレットとリモートSatellite Server間で10回のラウンドトリップが必要になります。ただし、外部リスト・テンプレート自体をキャッシュするようにしながら、サブページレットに対する既存の<render:calltemplate>コールがstyle="embedded"を使用するよう設定されている場合は、製品リスト・ページレット全体に対して必要なのは1回のラウンドトリップのみです。これは、外部テンプレートのみがリモートSatellite Serverによって処理され、残りのサブページレットはContentServerサーブレット上でのみ処理されるからです。
キャッシュ済ページレットすべてに対してcidが渡される場合、キャッシュはWebページ間で共有されません。たとえば、1つのサイトに5,000のWebページが含まれ、これらすべてによってcidがleftnavに渡される場合があります。また、コール元のWebページとは関係なく5,000のleftnavがキャッシュされます。このシナリオの場合、次の2つの状況が考えられます。
サイト・ナビゲーション・ツリー内の単一のページ・アセットが編集およびパブリッシュされる場合、5000のleftnavはすべてキャッシュされません。これは、パブリッシュされたばかりのページ・アセットにより、すべてのleftnavページレットに対して依存性が記録されるからです。
単一の記事アセットが編集およびパブリッシュされる場合、キャッシュ済外部Webページ(通常はレイアウト・テンプレート)とleftnavがキャッシュされず、再評価が必要になります。cidはleftnavに渡されるため、Content Serverは、外部Webページだけでなくleftnavもキャッシュしません。記事はサイト・ナビゲーション階層とは関係ないため、このアプローチは効率的ではありません。
これらの状況でキャッシュの容量オーバーを回避するには、cidのみではなくページのcidも常に使用されるようleftnavを変更します。コール元のテンプレートが所属先のページを確認することにより、これをキャッシュ引数として渡すことができるようにする必要があります。ページのcidのみがキャッシュ依存性をページレットに記録し、他のページ・アセットは記録しないようにする必要があります。擬似コードは、次のとおりです。
If c is not "Page"
then
Calculate the site navigation PageNode by doing a reverse look up of the Page from the current asset's cid.
Alternatively, have the site navigation Page as an attribute of the current asset and simply fetch it.
then calculate the PageNode from that
else
Calculate the PageNode from the current Page cid.
この方法により、このページレットのキャッシュ済バージョンが所有者の関連ページ・アセットのみにバインドされます。サイト・ナビゲーション・ツリー内の単一のページ・アセットが編集およびパブリッシュされる場合、cid=<the current Page asset>である単一のleftnavのみがキャッシュされません。単一の記事アセットが編集およびパブリッシュされる場合、キャッシュ済外部Webページ(通常はレイアウト・テンプレート)のみの再評価が必要になります。
編集者がシステムを毎日更新および変更する場合、開発者の選択内容がシステムの効率性に多大な影響を及ぼします。提案された改善を行わない場合、単一のアセットを編集するだけでも、パブリッシュ時にシステムが行う処理が必要以上に増える原因となる可能性があります。各ページレットに明示的に渡される引数は、パフォーマンス全体に直接影響を及ぼします。
