| Oracle® Fusion Middleware Oracle WebCenter Sitesの管理 12c (12.2.1.1) E77293-01 |
|
 前 |
 次 |
inCacheはメモリーベースのページおよびアセット・キャッシング・システムで、これを使用すると、WebCenter Sitesのデータを中央の共有リポジトリや共有ファイル・システムにキャッシュする必要がなくなります。inCacheは、Terracotta社によるオープン・ソースのJavaキャッシング・フレームワークであるEhcacheに基づいており、任意のキャッシング・システム上に実装できます。(Ehcacheの詳細は、http://ehcache.org/を参照してください。)
注意:
WebCenter Sitesは、Ehcacheを使用して、コンテンツを様々なレベルでキャッシュします。サイト・クラスタ内のノードの1つでネットワーク障害が発生すると、Ehcacheは非同期になる場合があります。様々なノードでのキャッシュの同期を保つには、ネットワーク障害が発生しているノードを再起動することをお薦めします。この項では、次の項目について説明します。
inCacheフレームワークは、レガシーのページ・キャッシング・フレームワークに置き換わるものです。inCacheでは、デフォルトでアセットのキャッシングもサポートしています。inCacheフレームワークには次のような利点があります。
高パフォーマンス。レスポンスが速いので、パブリッシング・セッションの頻度を上げることができます。ページおよびアセットの効果的な無効化により、更新済コンテンツがすばやく提供されます。
分散化アーキテクチャ。ノードはそれぞれ独自のローカル・キャッシュを維持しています。inCacheフレームワークでは、データベースのキャッシングと共有ディスクが排除されています。
ブロードキャスト・システム。個別のノードがキャッシュ全体の完全なビューを持つ必要がなくなりました。コンテンツへの変更をリスニングしているノードが、個々のコンテンツの必要に応じてブロードキャストに応答します。
リニアなスケーラビリティが強化され、ディスクやメモリーのデータに対して拡張。
フェイルオーバーと永続性。シャットダウンされたノードはローカル・キャッシュ内にデータを保持し、再起動時に、中央管理されている無効化のレコードに対して自己更新します。
オンデマンドのページ評価と無効化。ノードは、コンテンツがリクエストされたときのみ、現在キャッシュされているコンテンツを有効化して更新します。
この章では、主にページ・キャッシングについて説明します。ここでは、「ページ」という用語を、ページ・アセットでなく、レンダリング済ページを意味するものとして使用します。アセットのキャッシングに関する説明を理解するために、この章、特にinCacheの仕組みの理解を最初に読み、キャッシュ・コンテナと、その相互に関連した機能に関する基本を理解しておくことをお薦めします。
inCacheはディスクのストライプ化をサポートし、donoteregenerateフラグを非アクティブ化することでリアルタイム・パブリッシュに影響を与えます。リアルタイム・パブリッシュの間にページの再生成を有効にするオプションでは、配信システムのFW_RegenCriteria表に、クロールおよび再生成されるページのURLを移入する必要があります。ページ伝播も1つのオプションで、すべてのノードが同じページをホストするようにして、各ノードでページを再生成する必要をなくす場合に使用します。さらに、代替ページが再生成されるまでの少しの間、失効したページを引き続き提供するように、リモートのSatellite Serverを構成することもできます。
注意:
必要に応じて、次の手順を実行することで、レガシーのページ・キャッシング方法に戻すこともできます。
すべてのWebCenter SitesノードとSatellite Serverノードで、–Dcs.useEhcache=falseのようにVM引数を設定します
すべてのWebCenter SitesノードとSatellite Serverノードを再構成して、データベースと共有ファイル・システムを使用するようにします。
無効化以降に古くなってしまっている可能性が高い状況での、操作を再開する前のレガシー・ページ・キャッシュの消去。
一般的に、キャッシュ方法を切り替える場合には、WebCenter SitesノードとSatellite Serverノードが同じキャッシュを使用するように再構成して、使用前にキャッシュを消去する必要があります(ベスト・プラクティスとして推奨)。
アセットのキャッシングは、インストール時とアップグレード時にWebCenter Sitesシステム上で有効になります。アセットのキャッシングは、inCacheフレームワーク上に構築された、メモリーをベースにしたシステムで、そのままではデータベースに影響を与えるような負荷を担うことによってパフォーマンスを保護します。アセットのキャッシングにはAssetCacheコンテナという独自のコンテナが使用され、このコンテナは、他のinCacheコンポーネント(特にdependencyRepositoryキャッシュとnotifierキャッシュ)と相互に作用することによって機能します。
pageByQueryキャッシュは、アセットのキャッシングでは使用されませんが、キャッシュ・コンテナの仕組みの説明には便利です。それに相当するAssetCacheコンテナが同様に機能します。アセットのキャッシングとinCacheページ・キャッシングは、互いに独立に機能します。キャッシュの各タイプは、互いに関係なく有効または無効にできます。
AssetCacheコンテナの使用では、AssetCacheコンテナ、アセットのロードと無効化に関連する機能、アセット・キャッシングとページ・キャッシングの比較、およびアセットのキャッシングをアセット・タイプによってカスタマイズする方法について説明します。
クラスタ化された環境では、inCacheはクラスタのデータベースの外側の分散化されたアーキテクチャに実装されます。図25-1に示すように、各ノードにはそれぞれ独自のローカル・キャッシュがあります。各WebCenter Sitesノードは、他のWebCenter Sitesノードからのブロードキャストをリスニングすることで、ローカル・キャッシュを最新に保ち、HTTPを介してリモートのSatellite Serverに更新を伝達します。
ノードのローカル・キャッシュはパーティションで区切られています。
pageByQryキャッシュには、ノードのWebページが格納されます。
dependencyRepositoryキャッシュには、Webページを構成するアセットの識別子が格納されます。
注意:
pageByQryキャッシュは、ページ・キャッシュとも呼ばれます。dependencyRepositoryキャッシュは、依存性キャッシュとも呼ばれます。
notifierキャッシュは、編集またはパブリッシュのプロセスで変更されたアセットの識別子をブロードキャストします。ブロードキャストは、アセットの変更されたノードによって開始されます。リスニングするノードがブロードキャストに応答する方法は、ノードによって異なります。例:
ノードAのWebCenter SitesユーザーがアセットAを編集します。
ノードAのnotifierキャッシュが、その他のすべてのノードに変更の通知をブロードキャストします。
アセットAを含むすべてのWebCenter Sitesノードが、それぞれ独自のローカル・キャッシュ内のアセットを無効化することで応答します。各ノードは独自のdependencyRepositoryキャッシュを参照し、アセットの識別子を無効にマークして、キャッシュ全体の依存性生成数を増分させます。無効化されたアセットは、そのアセットを参照するページで使用できなくなるので、これらのページそのものも無効になります。ただし、ノードは、ページがリクエストされるまでページを評価しません。ここにパフォーマンス上の利点があります。
無効化されたアセットに対する依存性を持つページのリクエストにノードが応答する場合、このノードはpageByQryキャッシュを参照し、ページを評価し、無効化するページを決定し、それをフラッシュし、新規ページを生成し、そのページを訪問者のブラウザに提示して、ローカル・キャッシュ内に新規ページとその依存性を記録します(依存性は、ページを構成するアセットの識別子として記録されます)。その時点から、ページが異常終了するか、アセットが再び無効化されるまで、ノードのローカル・キャッシュからは同じページが提示されます。
WebCenter SitesとSatellite Serverは同じキャッシング・フレームワークを使用していますが、Satellite Serverノードは、HTTPを介してWebCenter Sitesノードと通信しています。
注意:
pageByQueryキャッシュはページ・キャッシングにしか使用されませんが、キャッシュ・コンテナの仕組みの説明には役立ちます。アセットのキャッシングの場合、inCacheフレームワークでは、それに相当するAssetCacheという名前のコンテナが使用されます。それはpageByQueryと同様の方法で機能し、dependencyRepositoryおよびnotifierキャッシュと対話します。アセットのキャッシングの詳細は、アセットのキャッシング操作の使用を参照してください。
WebCenter SitesまたはSatellite Serverノードが停止している場合、そのキャッシュにあるデータは保持されますが、アクティブ・ノードが引き続きアセットを無効化するため、すぐに古くなります。その結果、ノードを再起動するには、それが持つキャッシュを更新する必要があります。再起動時の更新を保証するのが共通の無効化メモリーで、それはWebCenter Sitesクラスタのデータベースに表として格納され、クラスタのすべてのノードが再起動時に使用できる状態に維持されます。表の名前はFW_InvalidationMemoryです。
無効化メモリーには、アセット無効化のレコード(特に、コンテンツ管理またはパブリッシュ・プロセスで変更または削除されたアセットの識別子)が格納されます。15分間隔で実行されるクリーンアップ・メカニズムにより表の増大がチェックされ、最も古い期間の無効化レコードが破棄されます。
ノードは再起動時に、非アクティブであった期間に欠落した情報をリカバリしようとして、無効化メモリーを参照します。
ノードの非アクティブ期間の無効化レコードが存在する場合、ノードは自分自身でリプレイします。
非アクティブ期間に無効化されたアセットが存在しない場合、ノードはシャットダウンされなかったかのように動作を続行します。
ノードが非アクティブであった間にクリーンアップ・メカニズムによって無効化レコードが消去された場合、ノードのキャッシュは自らを破棄するので、再構築する必要があります。
リモートのSatellite Serverは、WebCenter Sitesに更新を求めるリクエストを送信することによって失った情報を、再起動時に取得します。
inCacheを有効にすると、リアルタイム・パブリッシュ・プロセス用のdonotregenerateフラグが無効になります。このフラグが認識されなくなるので、リアルタイム・パブリッシュ・セッション時のページの再生成には、クロールが使用されます。クローリングを実装していなければ、ページはリクエスト時のみ再生成されます。
クロール・オプションでは、ページ・リジェネレータによって分析される一連のURLを指定する必要があります。通常、これらはホームページやその他のトラフィックの多いページのURLです。それらのページをクロールする深さを指定することもできます。たとえば、深度1では指定したページとそれらのページのリンク先のページがクロールされ、0では指定したページのみがクロールされます。クロールされるページは、そのコンポーネント・アセットがパブリッシュ・セッション時に無効化された場合か、それらのページがキャッシュされていない場合のみ再生成されます。指定したページ上のすべてのページレットがプロセス内で再生成されます。
URLとクロール深度のリストを、inCache構成後の最初のパブリッシュ・セッション時に配信システム上で作成されるFW_RegenCriteria表で指定する必要があります。ft_ssパラメータをURLに含むことで、ページ・リクエストをWebCenter Sitesで直接処理するのか、リモートのSatellite Serverによって処理するのかを指定できます。inCacheの構成とページ再生成の有効化の詳細は、アセットのキャッシング操作の使用を参照してください。
WebCenter Sitesのダブルバッファによるページ・キャッシング方法では、ライブWebサイト上でWebCenter SitesとSatellite Serverのキャッシュを連結させて使用します。ダブル・バッファリングでは、ページが常にWebCenter SitesかSatellite Serverのいずれかのキャッシュ内に保持され、ページ・リクエストの過負荷からWebCenter Sitesを保護し、ライブWebサイトで空白ページやリンク切れが表示されないようにします。
inCacheフレームワークで従来のシステムのダブルバッファ・キャッシングを維持するために、HTTPリクエストを介してリモートのSatellite ServerはWebCenter Sitesと通信を続けるようになっています。Satellite Serverはこれまでどおりの方法で、HTTPリクエストを介してページ・データを読み取ってキャッシュします。ただし、ページ・データには、アセット識別子のカンマ区切りのリスト形式で依存性情報が含まれるようになり、この情報はリモートのSatellite Serverにもストリームされます。
この構成プロセスは、一連の必須の手順とオプションの最適化手順によって構成されます。たとえば、複数のWebCenter Sitesノードの相互通信を有効にして、WebCenter SitesとリモートのSatellite Server上の各ローカル・キャッシュのストレージ・プロパティを設定します。
inCacheページ・キャッシング用にシステムを構成するには::
inCacheによるページのキャッシングが有効になっていることを確認します。VM引数–Dcs.useEhcacheを検索して、これがtrueに設定されているか、何も設定されていない(その場合の値はtrueと想定される)かのどちらかであることを確認します。
システムの再起動時に、WebCenter SitesノードとSatellite Serverノードのそれぞれで、キャッシュ・コンテンツが保持されるように構成します。次のVM引数を渡します。
–Dnet.sf.ehcache.enableShutdownHook=true
オプションの最適化。各WebCenter SitesおよびSatellite ServerノードにdiskStoreパスを設定します。複数のノードが同じシステム上にある場合(垂直クラスタ)は、各ノードが固有のdiskStoreパスを持っていることを確認します。cs-cache.xmlおよびss-cache.xmlファイルで、diskStore path="<path to disk store>"プロパティを設定します。両方のxmlファイルが各WebCenter Sitesノードに格納されます。cs-cache.xmlはWebCenter Sites酔うで、ss-cache.xmlは共存するSatellite Server用です。リモートのSatellite Serverにはss-cache.xmlファイルのみが格納されます。これらのファイルはWEB-INF/classesフォルダの下に配置されます。
diskStoreプロパティに関する詳細は、次のEhcache Webサイトにあるドキュメントを参照してください。
http://ehcache.org/documentation/configuration.html
注意:
inCacheは、WebCenter Sites、リモートのSatellite Server、共存するSatellite Serverに存在しています。アーキテクチャと機能の面で、共存するSatellite ServerとリモートのSatellite Serverに存在しているinCacheは同じものです。ただし、共存するSatellite Serverには次の推奨事項が適用されます。
ディスクの永続性をオフにします。
各キャッシュのサイズは、WebCenter Sitesのキャッシュ・サイズよりも小さくします。これはメモリーの過負荷を防ぐためです。共存するSatellite Server上の完全なダブルバッファ・キャッシングに対する要件などの特別な状況を除いて、このサイズは小さくしておくことをお薦めします。
inCacheポートの構成。inCacheは、クラスタ・メンバー間の通信には、EhcacheのRMIベースのトランスポート・メカニズムを使用します。通常、これに追加の設定は不要ですが、Ehcacheが使用する正確なポートを指定することは可能です。クラスタ・メンバー間にファイアウォールがある場合、これは特に重要です。
特定のポートを使用するようにEhcacheを構成する方法の詳細は、次のEhcache Webサイトのドキュメントを参照してください。
http://ehcache.org/files/documentation/EhcacheUserGuide-1.6.pdf
複数のノードに必要な手順です。WebCenter Sitesクラスタに対して自動ノード検出を構成します(Satellite Serverノードはクラスタ化できません)。例として、この手順では、CS1、CS2、CS3という名前の3つのWebCenter Sitesノードを使用します。
注意:
ある場合には、inCacheノード・ネットワーク上のファイアウォールにより、ノード間の通信が阻害されます。複数のノードにinCacheをインストールして構成する場合、それらのファイアウォールを無効にします。検証が済んだら、システム管理者/ネットワーク管理者は、inCacheテストおよびRemote Satellite Serverへのページ伝播の際にポートを監視し、それに応じてファイアウォールを適応させてください。
各WebCenter Sitesノードで、cs-cache.xmlとss-cache.xml (WEB-INF/classesにある)でcacheManagerPeerListenerFactoryが指定されていることを確認します。これはCacheManagerPeerProviderを作成するために使用されます。このプロバイダがクラスタ内の他のノードを検出します。次の例に示すように、自動検出を構成します。
<cacheManagerPeerProviderFactory class="net.sf.ehcache.distribution.RMCacheManagerPeer ProviderFactory" properties="peerDiscovery = automatic, multicastGroupAddress = 230.0.0.1, multicastGroupPort = 4444, timeToLive = 32"/>
注意:
multicastGroupPortプロパティは、クラスタ・メンバー全体に対して同一に設定する必要があります。たとえば、CS1のcs-cache.xmlファイル内でmulticastGroupPort=4444と指定されている場合、CS2とCS3でもそれぞれのファイル内で同じ設定を指定する必要があります。
timeToLiveプロパティは、1つのパケットに対して許可されるホップの数を指定するもので、これによってパケットの伝播距離が決まります。有効な値範囲は、0から255の間で、次の制約があります。
0: 同一ホスト
1: 同一サブネット
32: 同一サイト
64: 同一範囲
128: 同一大陸
255: 無制限
すべてのSatellite Server(共存およびリモート)で、次のいずれかを実行します。
各ss-cache.xmlファイル内のmulticastGroupPortプロパティを一意の値に設定します。
キャッシュのレプリケーションをサポートする場合は、各ss-cache.xmlファイル内のmulticastGroupPortプロパティを同一の値に設定します。
注意:
ss-cache.xmlファイルに設定する値は、cs-cache.xmlファイル内にあるWebCenter SitesのmulticastGroupPortプロパティとは別の値にする必要があります。
inCacheが構成されている場合、cs-cache.xmlおよびss-cache.xmlに指定された構成を使用してシステムが起動します。キャッシュは、WebCenter Sites内のいずれかのページ(キャッシュされるかどうかにかかわらず)を最初にコールした時点で初期化されます。
オプションの最適化。必要に応じて、表25-1をプロパティ・リファレンスとして使用して、ローカル・キャッシュを構成します。WebCenter SitesとリモートのSatellite Serverの各ノードのローカル・キャッシュは、パーティションで区切られています。各部分は、cs-cache.xmlファイルとss-cache.xmlファイルにある独自の<cache>タグで定義されます。各部分の名前は次のとおりです。
pageByQry: ページ・データそのもののキャッシュで、問合せのURLによるキーが設定されています。
dependencyRepository: ページ構築の基礎となる依存性のキャッシュです。pageByQryキャッシュにページが追加されると、dependencyRepositoryキャッシュにエントリが自動的に作成されます。このキャッシュ内の各エントリは、アセットのid、unknowndepまたはunknowndep-<type>のいずれかです。したがって、このキャッシュには最大でもシステム内のアセット数と、様々なバリエーションのunknowndepの少数のアイテムが格納されるのみです。
依存性のないページがキャッシュされると、そのページが_NODEP_ (依存性のないページの識別に使用されるdependencyRepositoryキャッシュ内の1つのアイテム)に依存性をログ記録します。_NODEP_アイテムとページとの関連付けは、そのページが異常終了するか手動でフラッシュされるまで維持されます。リモートのSatellite Serverでは、(Satellite Serverごとに)JVMオプションの
-Dignore_nodep_pagesをtrueに設定することで、依存性のないページのキャッシュを無効にできます。
notifier: このキャッシュは、アクティブなWebCenter Sitesクラスタ・メンバーが他のWebCenter Sitesクラスタ・メンバーにコンテンツの変更を通知するために使用します。
構成されたすべてのWebCenter SitesノードとSatellite Serverノードを再起動します。
すべてのアクティブなクラスタ・メンバーがキャッシング・ネットワーク内にあり、互いを認識していることを検証します。「クラスタ情報」診断ツールを使用すると、notifierキャッシュを持つすべてのWebCenter Sitesメンバーがリストされます。「クラスタ情報」をコールするには:
キャッシュ可能なページをレンダリングすることで、inCacheをブートストラップします。
一般管理者(デフォルトではfwadmin/xceladmin)として、WebCenter Sites Adminインタフェースにログインします。
WebCenter Sitesのクラスタ・メンバーと、共存するSatellite Serverが、相互に通信していることを確認します。「管理」タブを開き、「システム・ツール」、「キャッシュ管理」、「Sitesキャッシュ」の順に開き、「クラスタ情報」をダブルクリックします。
キャッシュ構成ツールでは、様々なタイプのページ・キャッシュ統計を使用できます。詳細は、システム・ツールを使用したトラブルシューティングを参照してください。
ディスク・ストライプの必要がある場合は、リアルタイム・パブリッシュ時のページの再生成を有効にするか、ページ伝播を有効にします。詳細は、チューニング・オプションを参照してください。
表25-1 キャッシュ構成プロパティ
| プロパティ | 必須かどうか | 説明 |
|---|---|---|
|
Y |
キャッシュの名前を指定します。 有効な値:
詳細は、手順5を参照してください。 |
|
N |
JVMの再起動と再起動の間にディスク上にデータを保持するかどうかを指定します。 デフォルト/推奨値: 注意: |
|
Y |
メモリーに格納するオブジェクトの最大数を指定します。 デフォルト値: |
|
Y |
ディスクに格納するオブジェクトの最大数を指定します。ディスクはストライプ化できます。詳細は、ディスク・キャッシュのストライプ化を参照してください。 デフォルト値: |
|
Y |
WebCenter Sitesによってキャッシュを消去するかどうかを指定します(inCacheによって消去されることはありません)。 デフォルト値: このプロパティの値を変更しないでください。 |
|
Y |
メモリー・キャッシュをディスクベースのキャッシュにオーバーフロー可能にするかどうかを指定します。 デフォルト値: このプロパティの値を変更しないでください。 |
|
N |
ディスク・バッファのサイズを指定します(MB単位)。大量のディスクI/Oが予想される場合(ディスク・キャッシュがメモリー・キャッシュよりはるかに大きい場合など)は、バッファを20MBに設定します。 デフォルト値: |
|
N |
キャッシュからアイテムを削除する方法を指定します。推奨されるデフォルト値は、 デフォルト/推奨値: |
|
N |
メモリーがディスクにフラッシュされるときにこれを消去するかどうかを指定します。 デフォルト値: このプロパティの値を変更しないでください。 |
inCacheフレームワークには多くのオプションがあり、システムにあわせて最適化できます。この項には、それらのオプションをまとめました。
inCacheフレームワークでは、キャッシュの大部分をディスクに書き込む必要があるときに発生する競合をなくすために、pageByQryキャッシュのストライプ化をサポートしています。
inCacheフレームワークでは、WebCenter SitesノードとリモートのSatellite Serverに対して次の手順を実行します。
pageByQryキャッシュをストライプ化するには::
この例では、ルート・キャッシュに依存性とnotifierキャッシュが格納されています。ディレクトリ0から4に拡散しているのは、pageByQryキャッシュのストライプです。この例の0から4のディレクトリは、シンボリック・リンクの使用によって5つの別個のドライブに配置されました。
ページは、リクエストされた場合のみ再生成されます。
リアルタイム・パブリッシュ時のページの再生成を構成するには::
デフォルトでは、PageCacheUpdaterが、WebCenter Sitesインストーラによって、ParallelCacheRegeneratorを使用するように設定されます。
WebCenter Sitesの配信システム上のWEB-INF/classesフォルダにあるAdvPub.xmlファイルを開き、PageCacheUpdaterセクションに次に示すコード行があることを確認します。
注意:
次に示すもの以外は、PageCacheUpdaterセクションの値を変更しないでください。
numThreadsPerServer: クロールするときの同時スレッド数を指定します。
regenServers: <address>と<port of server where pages will be regenerated>によって、WebCenter Sitesノードを指定します
<bean id="PageCacheUpdater"
class="com.fatwire.realtime.regen.ParallelRegeneratorEh" singleton="false">
<property name="id" value="CacheFlusher" />
<property name="numThreadsPerServer" value="3" />
<property name="regenServers">
<list>
<value>http://address:port of server where pages are regenerated/
servlet/ContentServer</value>
</list>
</property>
</bean>
配信システムを再起動します。
WebCenter Sitesの配信システムに対してリアルタイム・パブリッシュが行われ、そのシステム上にFW_RegenCriteria表が作成されます。
Oracle WebCenter Sites Explorerを使用して、FW_RegenCriteria表を開きます。再作成するページと、フォローするリンクの深さ指定します。ft_ssパラメータをURLに含むことで、ページ・リクエストをWebCenter Sitesで直接処理するのか、リモートのSatellite Serverによって処理するのかを指定できます。
注意:
URLアセンブラを使用する場合は、クロールするページの内部URLを指定します。リジェネレータはURLアセンブラのURLを認識しません。
例:
pagename=SiteName/HomePage&ft_ss=true Level=1
WebCenter SitesによってHomePageと、HomePageからリンクされるページが再生成されます。ft_ss=trueと指定した場合、Satellite Serverで生成されたもののように、リクエストが処理されます。
WebCenter Sitesの配信システムにリアルタイム・パブリッシュを行います。
パブリッシュ・セッションの間、配信システムはFW_RegenCriteria表で指定されたすべてのページをクロールしますが、再生成するのはコンポーネント・アセットが無効化されたものだけです(未キャッシュのページも生成します)。
例:
更新されたアセットが配信システムにパブリッシュされます。
配信システムは、dependencyRepositoryキャッシュ内でアセットの識別子を無効にマークし、依存性生成数を増分させることで、再パブリッシュされたアセットの既存の依存性情報を無効化します。無効化されたアセットは、そのアセットを参照するページで使用できなくなるので、これらのページも無効になります。
ページ・リジェネレータは、FW_RegenCriteria表に指定されているURLを使用してページをクロールし、無効化されたページを再生成します。さらに、未キャッシュのページも生成します。
ページ伝播によって、WebCenter Sitesクラスタ内のすべてのノード(Satellite Serverノードを含む)が同じページをホストでき、それぞれのノードがページを再生成する必要がなくなります。
inCacheを使用するように構成した場合は、各WebCenter Sitesが別個のJVMを持ち、別々のローカル・キャッシュを維持することになります。1つのWebCenter Sitesによって新しいページが生成され、キャッシュされても、その他のWebCenter Sitesで新しくページがキャッシュされたり、そのページについて通知されることはありません。同じページに対するリクエストを受信すると、各ノードがデータベースや共有のファイル・システムを参照することでそのページを生成する必要があり、両方のコンポーネントに余分な負担が課せられます。ページ伝播では、クラスタ全体にページが伝播されるので、別々のノードが同じページを再生成しなくてもよくなります。
ページ伝播は、ノードのローカル・キャッシュにページがロードされたときに引き起こされます。この機能は、inCacheの基本機能から始まる、次のシナリオに示すように機能します。
新しく生成されたページに対するinCacheのページ・キャッシング:
ノードA (WebCenter Sitesノード)が、新規ページのリクエストを受信します。
ノードAが、リクエストされたページを生成します。
ノードAは、新規ページと完全な依存性情報(コンポーネント・アセットの識別子)を、ローカル・キャッシュと依存性キャッシュにキャッシュします。
ページ伝播が有効な場合は、手順3に続きます。
再生成されたページに対するinCacheのページ・キャッシング:
ノードBもWebCenter Sitesノードで、無効化されたページに対するリクエストを受信します(コンポーネント・アセットが変更されました。このアセットは、ノードBのローカルの依存性キャッシュと、アセットを含むその他すべてのノードの依存性キャッシュで、無効としてマークされています)。
ノードBが、リクエストされたページを再生成します。
ノードBは、再生成されたページをキャッシュし、生成数を増分させることで依存性を更新します(手順2a)。
ページ伝播が有効な場合は、手順3に続きます。
ページ伝播によるinCacheのページ・キャッシング:
ノードは、ページを(再)生成するときに、その他のノードにもこのページを伝播します。伝播される情報は、次の内容で構成されています。
ページの完全な依存性情報。たとえば、ページにxの依存性(アセット識別子)が存在する場合は、xの依存性がすべて、ローカルの依存性キャッシュから他のWebCenter Sitesノードの依存性キャッシュに伝播されます。
ページ自体。ページは、ローカルのページ・キャッシュから他のWebCenter Sitesノードのページ・キャッシュに伝播されます。
受信側のノードにページが存在している場合、そのノードは伝播を無視します。
次のリストでは、ページ伝播のイベントと条件をまとめています。
WebCenter Sitesノードでページがキャッシュされた場合、その完全なページ情報(前述の手順3を参照)が、その他すべてのWebCenter Sitesノードに伝播されます。
リモートのSatellite Serverノードでページがキャッシュされた場合、その完全なページ情報(前述の手順3を参照)が、Java RMI (Remote Method Invocation)を経由して他のSatellite Serverに伝播されます。
ページが伝播されると、次のような処理が行われます。
そのページの最終更新時のタイムスタンプが、すべてのWebCenter SitesノードとSatellite Serverノードで保持されます。
所定のノードの再生数が、その他すべてのノードの再生数とは無関係に維持されます。たとえば、ノードAの再生数が10でも、他のノードは別のタイプの依存性の生成数に10を使用します。WebCenter SitesまたはSatellite Serverすべてに同じオブジェクトが伝播されても、WebCenter SitesノードまたはSatellite Serverノードごとに異なる生成数が割り当てられる場合もあります。オブジェクトとその最終更新/変更時間のタイムスタンプは、ノード全体で同じになります。
そのページが存在しているノードでは、伝播が無視されます。
キャッシュされたページの依存性を、そのページの存在しないノードに伝播できなかった場合、そのページがノード上でリクエストされて生成されるまで、ページはノード上にキャッシュされません。
それでもSatellite ServerキャッシュにはBLOBが格納されているので、それがSatellite Server全体にレプリケートされます。
この項の内容は次のとおりです。
inCacheを使用するように構成されたシステムを起動します。
ページ伝播を有効化するには::
すべてのWebCenter Sitesノード上で、次の手順を実行します。
プロパティ管理ツールで、propagatecache=trueを設定します。すべてのノードにこのプロパティを設定するために、「グローバル」を選択します。
cs-cache.xmlで、クラスタ内のすべてのWebCenter Sitesノードに対するmulticastGroupPortが同一で、相互に通信可能であることを確認します。(このファイルはWEB-INF\classesにあります。)
すべてのリモートのSatellite Serverで、次の手順を実行します。
リモート・サテライト・サーバーのwcs_properties.json ファイルで、propagatecache=trueを設定します。このファイルはconfigフォルダにあります。
注意:
Satellite Serverのconfigフォルダは、インストール時に、ユーザー定義の場所に配置されます。クラスタ化環境の場合、推奨される場所は、サイト共有ディレクトリ(<WCSITES_SHARED DIR>)配下です。非クラスタ化環境の場合、推奨される場所は、ホーム・ディレクトリ(<WCSITES_PRODUCT HOME>)の外です。configフォルダがない場合、インストールのエンジニアに問い合せてください。
ss-cache.xmlで、キャッシュ伝播するつもりのすべてのSatellite ServerでmulticastGroupPortが同一であるが、WebCenter SitesノードのmulticastGroupPortとは異なっていることを確認します。
すべてのノードで、任意のページをレンダリングすることでページ伝播を初期化して、システムが次のように応答することを確認します。
WebCenter Sitesノードでは、ページのキャッシュによって、ローカル・キャッシュから他のWebCenter Sitesノードのキャッシュへの伝播が引き起こされます(ページ伝播の設定の手順3を参照)。この間、すべてのWebCenter Sitesにわたり、ページの最終更新/変更時間のタイムスタンプが保持されます。そのページが存在しているWebCenter Sitesノードでは、伝播が無視されます。
Satellite Serverでの応答は、WebCenter Sitesノードでの応答と同じですが、こちらはJava RMIを経由しています。
リモートのSatellite Serverは、無効化されたページレットを提供する一方で、これがバックグラウンド・プロセスで再生成されるように構成できます。
無効化されたページレットを提供できるようにするには:
リモートのSatellite Serverのwcs_properties.jsonファイル(クラスタ化環境の場合、WCSites_Shared_Dir配下、非クラスタ化環境の場合、WCSites_Product_Home配下にあります)に、serveStale=trueを追加します。
それでもページレットが無効化されている場合は、次の方法で再生成します。
ブラウザが次の30分以内にページレットをリクエストする場合、リモートのSatellite Serverによって、ページを再生成するためのリクエストをWebCenter Sitesに送信するプロセスが、バックグラウンドで開始されます。バックグラウンド・プロセスの実行中、ブラウザには、リモートのSatellite Serverのキャッシュから、無効化されたページレットが提供されます。これ以降すべてのリクエストで、バックグラウンド・プロセスによってページレットが再生成されるまで、無効化されたページレットが提供されることになります。
ブラウザが30分経過後にページレットをリクエストする場合、リモートのSatellite Serverは通常のプロセスを使用してページレットを再生成します。つまり、ページレットを再生成するためのリクエストがWebCenter Sitesに送信されます。リクエスト側のブラウザは、ページが再生成されるまで待機する必要があります。
バックグラウンド・プロセスに関する情報を入手するには、logging-config.propertiesファイルで、com.fatwire.logging.cs.cache.ehcache loggerをDEBUGに設定します。
DEBUGによって、バックグラウンド・プロセスの開始時には次のメッセージが作成されます。
"Data for <cache key> is found to have been invalidated. A new request has started processing new data in the background."
プロセスの後で、次のメッセージが表示されます。
"Background process for request <cache key> has completed successfully, data in cache is updated."
WebCenter Sitesでは、アセットのプログラム的な使用は、その属性のロードと読込みで構成されます。アセットは、WebCenter Sitesに格納されているテンプレートによってロードされるため、AssetCacheはWebCenter Sitesノードでのみ使用されます。
AssetCacheは、inCacheフレームワークのコンポーネントです。pageByQryキャッシュと同様に、AssetCacheはinCacheフレームワーク内で各WebCenter Sitesノード下の独自のコンテナとして個別に使用できます。
AssetCacheコンテナは、各WebCenter Sitesのcs-cache.xmlファイル内でデフォルトで有効になっており、ここでは<cache>エレメントという名前で呼ばれています。AssetCacheコンテナは、すべてのタイプのアセットをキャッシングし、次に示すinCacheコンポーネントと相互に作用することで機能します。特定のタイプのアセットについては、追加のAssetCacheコンテナを構成できます。詳細は、アセットのキャッシングのタイプおよびアセットのキャッシングのカスタマイズを参照してください。
dependencyRepositoryキャッシュとの相互作用
AssetCacheにアセットをロードすると、表25-2に示すように、inCacheがdependencyRepositoryキャッシュ内にエントリを作成することで、そのアセットへの依存性をログ記録します。そのアセットを変更または保存すると、dependencyRepositoryキャッシュから依存情報が削除されるので、AssetCacheではこのアセットのエントリが無効になります。一般に、キャッシュされたアセットに対して保存または削除操作を実行すると、そのアセットは無効になります。
注意:
アセットのキャッシングが有効になっている場合、Oracle WebCenter Sites ExplorerまたはCatalogManager APIを使用してデータベース表にアセットを直接保存したり削除しないでください。この方法で保存および削除操作を実行しても、アセットのキャッシュは無効になりません。
notifierキャッシュとの相互作用
どれか1つのノードで無効化が行われると、notifierキャッシュによって他のノードに反映されます。このキャッシュは、どのアセットが変更されたかという情報を広める働きをします。受信したノードのAssetCacheにそのアセットが含まれている場合、そのノードはこの情報に従って独自のdependencyRepositoryキャッシュを更新します。
表25-2は、アセットのキャッシングがページ・キャッシングと独立して機能するが、なおも様々なキャッシュ・コンテナを共有する仕組みを示しています。
表25-2 アセットとページのキャッシングで使用されるキャッシュ・コンテナ
| アセットのキャッシング機能 | ページのキャッシング機能 | AssetCacheコンテナ | pageByQryコンテナ | dependency Repositoryコンテナ | notifierコンテナ |
|---|---|---|---|---|---|
オフ |
オフ |
未使用 |
未使用 |
未使用 |
未使用 |
オフ |
オン |
未使用 |
ページのキャッシングで使用 |
ページのキャッシングで使用 |
ページのキャッシングで使用 |
オン |
オフ |
アセットのキャッシングで使用 |
未使用 |
アセットのキャッシングで使用 |
アセットのキャッシングで使用 |
オン |
オン |
アセットのキャッシングで使用 |
ページのキャッシングで使用 |
アセットのキャッシングとページのキャッシングで使用 |
アセットのキャッシングとページのキャッシングで使用 |
この項の内容は次のとおりです。
アセットのデータは、APIまたはasset:loadタグを使用する複数の方法で読み込むことができます。
次のAPIは、アセットを、readonly_completeモードでAssetCacheにロードします。
AssetDataManager.read(AssetId)
アセットに対するREST API GET
次のタグは、アセットをAssetCacheに、様々なモードでロードします。
asset:load(objectid="cid1" option="editable")
asset:load(objectid="cid1" option="readonly")
asset:load(objectid="cid1" option="readonly_complete")
optionパラメータでは、アセットをキャッシュするかどうかと、AssetCacheおよびdependencyRepositoryでの、キャッシュされたアセットのキーの命名方法を決定します。キャッシングのシナリオを、図25-3にまとめます。シナリオDでは、AssetCacheコンテナに同じアセットの複数のエントリが存在しています。これは、アセットがreadonlyおよびreadonly_completeという2つのモードでロードできるためです。
次のモードでは、アセットをキャッシュするかどうかと、AssetCacheおよびdependencyRepositoryでの、キャッシュされたアセットのキーの命名方法が決定されます。
図25-4に示すように、キャッシュされたアセットとページ、さらにそれぞれの依存性では、キーの名前が異なります。この違いを理解することは、(「管理」タブの「システム・ツール」ノードにある)キャッシュ管理ツールに表示されるキャッシング情報の解析に役立ちます。
たとえば、図25-4は、AssetCacheコンテナにおいて、キャッシュされたアセットのキーの名前がassettype:cid1:2であることを示しています。ここで最後の整数は、アセットが読み取られたモードを示します(2はreadonlyモード)。同じアセットがreadonly_completeモードでもロードされた場合、そのキーはassettype:cid1:3になります。アセットが複数のモードでコールされた場合、AssetCacheコンテナにはそのアセットに対する複数のエントリが確認されます(図25-3を参照)。
キャッシュされたページのキーは、pagenameで始まります。ページにはモードは適用されません。ページのキャッシュは1度しか行われません。
アセットのロードのモードの詳細は、アセット・ローディングの使用を参照してください。キャッシュ管理ツールの詳細は、システム・ツールを使用したトラブルシューティングを参照してください。
アセットは、次のAPIやタグ経由で保存された場合、AssetCacheからフラッシュすることができます。
API
REST API PUT
AssetDataManagerWrite
JSPタグ
asset:save
asset:saveall
asset:delete
asset:deleteassettype
asset:void
asset:rollback
asset:deleterevision
asset:undocheckout
insite:edit
XMLタグ
INSITE.EDIT
ASSET.VOID
ASSET.SAVE
ASSET.SAVEALL
ASSET.DELETE
WebCenter Sitesノードでアセットのキャッシングを有効にすると、そのノードにあるcs-cache.xmlファイルには、次の<cache>エレメントのどれか1つ以上が格納されます。
デフォルトの<cache>エレメント。すべてのタイプのアセットが、AssetCacheという名前の汎用のキャッシュ・コンテナにキャッシュされるように指定します。
<cache name="AssetCache"diskPersistent="true" maxElementsInMemory="100"maxElementsOnDisk="100" eternal="true" overflowToDisk="true"diskSpoolBufferSizeMB="20" memoryStoreEvictionPolicy="LFU"clearOnFlush="false" />
汎用のAssetCacheコンテナは、WebCenter Sitesのインストール・プロセス中に、すべてのWebCenter Sitesノードで自動的に構成されます。
カスタムの<cache>エレメント。特定のタイプのアセットが、AssetCacheAsset_type_nameという名前の独自のコンテナにキャッシュされるように指定します。
<cache name="AssetCacheAsset_type_name"diskPersistent="true" maxElementsInMemory="100"maxElementsOnDisk="100" eternal="true" overflowToDisk="true"diskSpoolBufferSizeMB="20" memoryStoreEvictionPolicy="LFU"clearOnFlush="false" />
タイプ固有のすべてのカスタムAssetCacheコンテナは、cs-cache.xmlファイル内で手動で構成する必要があります。タイプ固有のコンテナの作成数は、独自のコンテナにキャッシュする必要のあるアセットのタイプと、各コンテナのキャッシングに適用する必要のある条件によって異なります。
汎用のAssetCacheコンテナを、1つまたは多数のタイプ固有のアセット・キャッシュと共存させるか、あるいはそれらによって置き換えることができます。アセットがキャッシュするすべてのコンテンツは、排他的です。つまり、汎用のAssetCacheコンテナでは、タイプ固有のコンテナにキャッシュされているアセット・タイプは除外され、タイプ固有のコンテナでは、その他すべてのタイプのアセットが除外されます。
さらに、アセットのキャッシングが有効になっている場合、(「管理」タブの「システム・ツール」ノードにある)キャッシュ管理ツールには、AssetCacheコンテナのコンテンツ、dependencyRepository内の対応するエントリ、その他のタイプの情報を示すダイアログが表示されます。検索もサポートされます。
アセットのキャッシングの構成の詳細は、アセットのキャッシングのカスタマイズを参照してください。キャッシュ管理ツールの詳細は、システム・ツールを使用したトラブルシューティングを参照してください。
アセットのキャッシングをサポートするようにinCacheフレームワークが設定されているときに、アセットのキャッシングを無効化する場合は、次の手順を実行します。
inCacheフレームワークの各WebCenter Sitesノードで、cs-cache.xmlファイル(WEB-INF/classes/ディレクトリにある)を開き、名前がAssetCacheで始まる<cache>エレメントを削除します。選択した<cache>エレメントを削除するか、すべての<cache>エレメントを削除することができます。それぞれのエレメントはAssetCacheコンテナを表しています。AssetCacheコンテナのタイプの詳細は、アセットのキャッシングのタイプを参照してください。
アセットのキャッシングを構成する場合、キャッシュ管理ツールには、AssetCacheコンテナのコンテンツ、それに対応するdependencyRepository内のエントリ、その他の情報を示すダイアログが表示されます。検索もサポートされます。キャッシュ管理ツールの詳細は、システム・ツールを使用したトラブルシューティングを参照してください。
リモートSatellite Serverは、ページ・キャッシングでのみ使用されます。これは、ページ伝播やバックグラウンドでのページ再生成など、高度な機能をサポートするように構成できます。
ページ伝播
ページ伝播オプションによって、すべてのWebCenter SitesノードとSatellite Serverノードが同じページをホストできるようになり、それぞれのノードがページを再生成する必要がなくなります。ノードは生成および再生成されたページを、ページの(再)生成元およびキャッシュ元のノードから、ローカル・キャッシュに受信します。ページのキャッシングによって伝播が引き起こされます。ページ伝播の詳細は、ページ伝播の設定を参照してください。
バックグラウンドでのページの再生成
リモートのSatellite Serverは、無効化されたページレットを提供する一方で、これがバックグラウンド・プロセスで再生成されるように構成できます。詳細は、バックグラウンドでページレットを再生成するための構成を参照してください。
