| Oracle® Fusion Middleware WebCenter Sites管理者ガイド 11gリリース1 (11.1.1.8.0) E49682-01 |
|
 前 |
 次 |
inCacheによるページのキャッシングは、WebCenter Sitesのインストールまたはアップグレード時にデフォルトで有効になります。inCacheによるページのキャッシングは、レガシーのページ・キャッシング方法より優先されます。ローカル・キャッシュとpeer-to-peer通信を構成するために、WebCenter Sitesではcs-cache.xmlとss-cache.xmlという2つの構成ファイルが提供されます。
inCacheはディスクのストライプ化をサポートし、donoteregenerateフラグを非アクティブ化することでリアルタイム・パブリッシュに影響を与えます。リアルタイム・パブリッシュの間にページの再生成を有効にするオプションでは、配信システムのFW_RegenCriteria表に、クロールおよび再生成されるページのURLを移入する必要があります。ページ伝播も1つのオプションで、すべてのノードが同じページをホストするようにして、各ノードでページを再生成する必要をなくす場合に使用します。さらに、代替ページが再生成されるまでの少しの間、失効したページを引き続き提供するように、リモートのSatellite Serverを構成することもできます。
|
注意: 必要に応じて、次の手順を実行することで、レガシーのページ・キャッシング方法に戻すこともできます。
一般的に、キャッシュ方法を切り替える場合には、WebCenter Sitesノードと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サイトにあるドキュメントを参照してください(本書の記述時点でのURLは、http://ehcache.org/documentation/configuration.html)。
|
注意: inCacheは、WebCenter Sites、リモートのSatellite Server、共存するSatellite Serverに存在しています。アーキテクチャと機能の面で、共存するSatellite ServerとリモートのSatellite Serverに存在しているinCacheは同じものです。ただし、共存するSatellite Serverには次の推奨事項が適用されます。
|
複数のノードに必要な手順です。WebCenter Sitesクラスタに対して自動ノード検出を構成します(Satellite Serverノードはクラスタ化できません)。例として、この手順では、CS1、CS2、CS3という名前の3つのWebCenter Sitesノードを使用します。
各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の間で、次の制約があります。
|
すべてのSatellite Server(共存およびリモート)で、次のいずれかを実行します。
各ss-cache.xmlファイル内のmulticastGroupPortプロパティを一意の値に設定します。
キャッシュのレプリケーションをサポートする場合は、各ss-cache.xmlファイル内のmulticastGroupPortプロパティを同一の値に設定します。
|
注意: ss-cache.xmlファイルに設定する値は、 |
inCacheが構成されている場合、cs-cache.xmlおよびss-cache.xmlに指定された構成を使用してシステムが起動します。キャッシュは、WebCenter Sites内のいずれかのページ(キャッシュされるかどうかにかかわらず)を最初にコールした時点で初期化されます。
オプションの最適化。必要に応じて、表28-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キャッシュ」の順に開き、「クラスタ情報」をダブルクリックします。
キャッシュ構成ツールでは、様々なタイプのページ・キャッシュ統計を使用できます。詳細は、第30章「システム・ツール」を参照してください。
ディスク・ストライプの必要がある場合は、リアルタイム・パブリッシュ時のページの再生成を有効にするか、ページ伝播を有効にします。詳細は、第28.3項「チューニング・オプション」を参照してください。
表28-1 キャッシュ構成プロパティ
| プロパティ | 必須 | 説明 |
|---|---|---|
|
|
はい |
キャッシュの名前を指定します。 有効な値:
詳細は、手順4を参照してください。 |
|
|
いいえ |
JVMの再起動と再起動の間にディスク上にデータを保持するかどうかを指定します。 デフォルト/推奨値: 注意: |
|
|
はい |
メモリーに格納するオブジェクトの最大数を指定します。 デフォルト値: |
|
はい |
ディスクに格納するオブジェクトの最大数を指定します。ディスクはストライプ化できます。詳細は、第28.3.1項「ディスク・キャッシュのストライプ化」を参照してください。 デフォルト値: |
|
|
|
はい |
WebCenter Sitesによってキャッシュを消去するかどうかを指定します(inCacheによって消去されることはありません)。 デフォルト値: このプロパティの値は変更しないでください。 |
|
|
はい |
メモリー・キャッシュをディスクベースのキャッシュにオーバーフロー可能にするかどうかを指定します。 デフォルト値: このプロパティの値は変更しないでください。 |
|
|
いいえ |
ディスク・バッファのサイズを指定します(MB単位)。大量のディスクI/Oが予想される場合(ディスク・キャッシュがメモリー・キャッシュよりはるかに大きい場合など)は、バッファを20MBに設定します。 デフォルト値: |
|
|
いいえ |
キャッシュからアイテムを削除する方法を指定します。推奨されるデフォルト値は、 デフォルト/推奨値: |
|
|
いいえ |
メモリーがディスクにフラッシュされるときにこれを消去するかどうかを指定します。 デフォルト値: このプロパティの値は変更しないでください。 |
inCacheフレームワークでは、キャッシュの大部分をディスクに書き込む必要があるときに発生する競合をなくすために、pageByQryキャッシュのストライプ化をサポートしています。
inCacheフレームワークでは、WebCenter SitesノードとリモートのSatellite Serverに対して次の手順を実行します。
pageByQryキャッシュをストライプ化するには:
ストライプ化を有効にするには、次のVM引数を追加します。
–DnumOfDiskStores=X
このXは、ストライプの数を示しています。ストライプ数は、ストライプ化できる一意のスピンドルの数に設定します(たとえば、5つのドライブがある場合はXを5に設定します)。
|
注意: ディスクベースのキャッシュのストライプ化に使用するドライブは、その他の目的には使用できません。 各DiskStoreのサイズは、xml構成ファイル内のmaxElementsOnDiskプロパティによって指定されているサイズです(表28-1を参照)。たとえば、5つのストライプを使用しており、maxElementsOnDiskが |
シンボリック・リンクを作成するか、ドライブを物理的に正しい場所にマウントして、ストライプが適切に分散されるようにします。
定義された各キャッシュ用のディレクトリが、diskStoreパス(第28.3.3項「ページ伝播の設定」の手順3で構成)の下に作成されます。各ディレクトリの下にも、0で始まる番号の付いた一連のディレクトリが作成されます。各ディレクトリは別々のドライブを指しています。
たとえば、–DnumOfDiskStores = 5と設定した場合、アイテムは、WebCenter Sitesのディスクベースのキャッシュ内に次のように格納されます。
<custom_path>/cs-cache: Directory: 0 Directory: 1 Directory: 2 Directory: 3 Directory: 4 File: dependencyRepository.data File: dependencyRepository.index File: notifier.data File: notifier.index <custom_path>/cs-cache/0: File: pageByQry.data File: pageByQry.index <custom_path>/cs-cache/1: File: pageByQry.data File: pageByQry.index <custom_path>/cs-cache/2: File: pageByQry.data File: pageByQry.index <custom_path>/cs-cache/3: File: pageByQry.data File: pageByQry.index <custom_path>/cs-cache/4: File: pageByQry.data File: pageByQry.index
この例では、ルート・キャッシュに依存性とnotifierキャッシュが格納されています。ディレクトリ0から4に拡散しているのは、pageByQryキャッシュのストライプです。この例の0から4のディレクトリは、シンボリック・リンクの使用によって5つの別個のドライブに配置されました。
ページは、リクエストされた場合のみ再生成されます。
リアルタイム・パブリッシュ時のページの再生成を構成するには:
デフォルトでは、PageCacheUpdaterが、WebCenter Sitesインストーラによって、ParallelCacheRegeneratorを使用するように設定されます。
WebCenter Sitesの配信システム上のWEB-INF/classesフォルダにあるAdvPub.xmlファイルを開き、PageCacheUpdaterセクションに次に示す行があることを確認します。
|
注意: 次に示すもの以外は、PageCacheUpdaterセクションの値を変更しないでください。
|
<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 will be regenerated/servlet/ContentServer</value>
</list>
</property>
</bean>
配信システムを再起動します。
WebCenter Sitesの配信システムに対してリアルタイム・パブリッシュが行われ、そのシステム上にFW_RegenCriteria表が作成されます。
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ノード上で、次の手順を実行します。
futuretense.iniプロパティ・ファイルにpropagatecache=trueを設定します。
cs-cache.xmlで、クラスタ内のすべてのWebCenter Sitesノードに対するmulticastGroupPortが同一で、相互に通信可能であることを確認します。(このファイルはWEB-INF\classesにあります。)
すべてのリモートのSatellite Serverで、次の手順を実行します。
satellite.propertiesファイルにpropagatecache=trueを設定します。
ss-cache.xmlで、キャッシュ伝播するつもりのすべてのSatellite ServerでmulticastGroupPortが同一であるが、WebCenter SitesノードのmulticastGroupPortとは異なっていることを確認します。
すべてのノードで、任意のページをレンダリングすることでページ伝播を初期化して、システムが次のように応答することを確認します。
WebCenter Sitesノードでは、ページのキャッシュによって、ローカル・キャッシュから他のWebCenter Sitesノードのキャッシュへの伝播が引き起こされます(第28.3.3項「ページ伝播の設定」の手順3を参照)。この間、すべてのWebCenter Sitesにおいて、ページの最終更新/変更時間のタイムスタンプが保持されます。そのページがすでに存在しているWebCenter Sitesノードでは、伝播が無視されます。
Satellite Serverでの応答は、WebCenter Sitesノードでの応答と同じですが、こちらはJava RMIを経由しています。
ノードに対して再起動時のページ伝播を有効にする場合、ノードがページ伝播を認識するために、ローカル・キャッシュを再初期化する必要があります。ローカル・キャッシュを再初期化するには、ノード上のキャッシュ可能なページをレンダリングします。キャッシングによって、ノードが他のノードにページを伝播し、他のノードによって伝播されたページを認識します。ローカル・キャッシュが再初期化されても、ノードが非アクティブだった期間に実行されなかった伝播が、そのノードの再起動時にそこで再作成されることはありません。
リモートのSatellite Serverは、無効化されたページレットを提供する一方で、これがバックグラウンド・プロセスで再生成されるように構成できます。無効化されたページレットを提供できるようにするには、リモートのSatellite Serverのsatellite.propertiesファイルに、serveStale=trueを追加します。それでもページレットが無効化されている場合は、次のいずれかの方法で再生成します。
ブラウザが次の30分以内にページレットをリクエストする場合、リモートのSatellite Serverによって、ページを再生成するためのリクエストをWebCenter Sitesに送信するプロセスが、バックグラウンドで開始されます。バックグラウンド・プロセスの実行中、ブラウザには、リモートのSatellite Serverのキャッシュから、無効化されたページレットが提供されます。これ以降すべてのリクエストで、バックグラウンド・プロセスによってページレットが再生成されるまで、無効化されたページレットが提供されることになります。
ブラウザが30分経過後にページレットをリクエストする場合、リモートのSatellite Serverは通常のプロセスを使用してページレットを再生成します。つまり、ページレットを再生成するためのリクエストがWebCenter Sitesに送信されます。リクエスト側のブラウザは、ページが再生成されるまで待機する必要があります。
バックグラウンド・プロセスに関する情報を入手するには、リモートのSatellite Serverのcommons-logging.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."
