| Oracle® Fusion Middleware WebCenter Sites開発者ガイド 11gリリース1 (11.1.1.8.0) E49681-03 |
|
 前 |
 次 |
この章では、WebCenter Sitesでのキャッシングの概要について説明します。キャッシュが有効または無効な場合に、Webサイトでコンテンツがどのようにフェッチおよび表示されるかを説明します。また、様々なキャッシュ・モードと、それらがCommunity-Gadgets Webアプリケーションのパフォーマンスとデータの一貫性に及ぼす影響について説明します。キャッシュを構成して、ユーザーが生成したコンテンツの処理を最適化する方法について説明します。
この章には次の項が含まれます。
図83-1に示すように(およびこの項で後述するとおり)、システムはリクエストを受信すると、別のサブシステムへリクエストをルーティングします。このサブシステムで、このリクエストの処理に必要な機能が実行されます。リクエストの結果はコンパイルされ、リクエストを行ったクライアントに送信されます。これらの結果は、ページの完全なコメント、特定の方法でソートされたコメント、レビューなどの形式になります。アプリケーションのパフォーマンスを改善するために、システムが同様のリクエストを受信したときに、即座に格納済の情報を検索および再利用して新しいリクエストに対応できるような方法で、これらの結果を格納できます。
|
ヒント: Community-Gadgets WebアプリケーションはWebCenter Sitesのデータ・リポジトリを使用し、RESTを通じてそのデータ・リポジトリと通信します。WebCenter Sitesは、受け取ったRESTリクエストをデータベース問合せに変換します。 |
Community-Gadgetsはそのデータベースからコンテンツをロードすると、WebCenter Sitesが提供するinCacheテクノロジを使用して作成されたインメモリー・キャッシュにコンテンツをキャッシュします。キャッシュは、最も一般的でよくある問合せに関するデータが格納された中間記憶域(RAM)です。キャッシュへのアクセスは、RAMが記憶域として使用されている非常に高速です。
キャッシュは、ネットワーク通信やデータのシリアライズに関するオーバーヘッドの削減に役立ちます。システムのパフォーマンスやスループットを向上させるには、リクエストの処理結果をキャッシュから提供する必要があります。
キャッシュ・テクノロジを使用してリクエストを処理する際には、キャッシュ・ヒットとキャッシュ・ミスという、2種類のイベントが発生します。キャッシュ・ヒットは、リクエストされたデータがすでにキャッシュ内に存在し、キャッシュから直接データを取り出してクライアントに返すことができる場合に発生します。キャッシュ・ミスは、リクエストされたデータがキャッシュ内に存在しない場合に発生します。この場合、最初にWebCenter Sitesのデータ・リポジトリからキャッシュにデータがコピーされ、それから後続のリクエストが処理されます。たとえば、ユーザーがコメントまたはレビューが投稿されたページを最初にリクエストする場合(つまり、そのページは以前にリクエストされていないか、またはキャッシュがフラッシュ済である場合)、Community-Gadgetsはそのページをキャッシュに保存します。別のユーザーがこのページをリクエストすると、Community-Gadgetsはキャッシュからそのページを取得します。ユーザーとCommunity-Gadgetsの間の相互作用の結果、アプリケーションはWebCenter Sitesからロードしたすべてのデータをキャッシュします。このキャッシュはインメモリー・キャッシュです。
次の項では、システムがキャッシュを扱う際の動作について説明します。
この項の内容は、次のとおりです。
Webサイトのページで訪問者がコメントやレビューなどのアイテムを作成、更新または削除すると、Community-Gadgetsは次の動作を行います。
WebCenter Sites内の関連するすべてのデータを変更します
関連するすべてのキャッシュ・エントリを無効にします
このように、Community-Gadgetsはシステム全体に対して、キャッシュ・エントリは失効して無効になっており、ユーザーのアクションに基づいて更新する必要があることを伝えます。たとえば、既存のコメントを編集する場合は、キャッシュ内にある特定のアイテムおよび編集されたコメントのディスカッションに関連付けられたデータ・コレクション全体を無効にする必要があります。今後のアクセスに備えて、無効になった値の更新がバックグラウンドで実行されます。
WebCenter Sitesはリモート・サーバーをサポートしており、RESTプロトコルで無効化リクエストを送信することによってリモート・サーバーのキャッシュ・コンテンツを最新に保ちます。これを可能にするには、SystemSatellite表にCommunity-Gadgets Webアプリケーションをリモート・サーバーとして登録します。Community-Gadgetsのインストールと構成の詳細は、『Oracle Fusion Middleware WebCenter Sitesインストレーション・ガイド』を参照してください。
Community-Gadgetsをサテライト・サーバーとして登録すると、Community-Gadgetsは変更されたデータに関する通知の受信を開始し、それに基づいてキャッシュの無効化を行います。データが変更されると、Community-Gadgetsの本番システムおよび管理システムを含むすべてのサテライトに通知が送信されます。図83-2は、そのプロセス・フローを示しています。
|
注意: 通知は同期的にブロードキャストされます。したがって、すべてのサテライトがこの無効化の受信の確認応答を行うまでは、変更リクエストは完了しません。 |
図83-2 WebCenter SitesとCommunity-GadgetsのSatellite Serverの間の通信
このプロセス・フローに示されているように、Community-Gadgetsはすべてのリクエストの結果をローカルのメモリーにキャッシュし、キャッシュの整合性を確保するために無効化通知を受け取ります。たとえば、Community-Gadgetsがリクエストの結果を収集、格納および送信した後で同様の内容のリクエストが到着すると、アプリケーションはキャッシュされたデータを返します。ただし、1回目と2回目のリクエストの時間枠の間に訪問者がなんらかの変更を行い、同じ時間枠内で無効化リクエストが行われた場合、2回目のリクエストではキャッシュからではなく、WebCenter Sitesのリポジトリからデータが提供されます。図83-3、図83-4および図83-5も参照してください。
Community-Gadgetsには、標準キャッシングと失効キャッシングという、2つのキャッシング・モードがあります。いずれのモードも、データの読取りでは同じアプローチをとります。要求されたデータがキャッシュにある場合は、そこから直接提供されます。データがキャッシュにない場合は、WebCenter Sitesのリポジトリから同期的にロードされます。したがって、ユーザー側のユーザー・インタフェースに結果が表示されるのは、load操作が完了し、データがキャッシュされた後です。ただし、データの無効化およびキャッシュの整合性の動作は、標準キャッシングと失効キャッシングで異なります。
Community-Gadgetsが特定のデータの無効化リクエストを受け取ると、Community-Gadgetsはキャッシュされたデータをすぐに無効にします。これにより、そのデータを要求する以降のすべてのリクエストではキャッシュ・ミスが発生し、WebCenter Sitesのリポジトリから新たにデータがロードされます。
図83-3は、標準キャッシング・モードでのキャッシュ・ヒット・イベントとキャッシュ・ミス・イベントのプロセス・フローを示しています。
標準キャッシング・モードでは、データの整合性レベルは高く、すべての変更はただちにインタフェースに反映されます。たとえば、ユーザーが新しいコメントを投稿してページをリフレッシュすると、新しいコメントはすぐにページに表示されます。同様に、ページから削除されたコンテンツは、ページをリフレッシュするとすぐに消えます。
Community-Gadgetsが無効化リクエストを受け取っても、データはすぐには無効化されず、消去もされません。これは、標準キャッシング(キャッシュ・データをすぐに無効にする)の場合とは対照的です。失効キャッシング・モードでは、Community-Gadgetsは特殊な無効化マークを使用して、有効でなくなったデータにマーク付けを行います。しかし、データはキャッシュ内に置かれたままであるため、引き続きキャッシュ・メモリーから提供できます。無効化されたデータを要求するリクエストを受け取ると、そのデータを更新するためのスレッドが起動されます。このプロセスは再生成サイクルと呼ばれます。
図83-4は、無効化されたデータがバックグラウンドで再生成された後、その再生成されたコンテンツがキャッシュから提供される様子を示しています。
失効キャッシング・モードでは、データ・ロードはバックグラウンドでシームレスに行われるため、パフォーマンス・レベルは高くなります。ただし、バックグラウンドでのデータ・ロードであるため、データの整合性レベルは標準キャッシング・モードよりも低くなり、訪問者は実際の結果をすぐには参照できません。たとえば、コメントを投稿した後で、そのコメントがページに表示されるまでには、何回かページをリフレッシュする必要があります。次のプロセスは、失効キャッシング・モードでの実行内容の説明です。
訪問者によるコメントの投稿: Community-Gadgetsは、特殊な無効化マークを使用してコメント・リストにマーク付けを行います。
訪問者による最初のページ・リフレッシュ: Community-Gadgetsは、キャッシュからの新しいコメントが含まれていない古いデータを引き続き提供しますが、特殊マークを検出し、バックグラウンドでの更新プロセスを開始します。
訪問者による2回目のページ・リフレッシュ: バックグラウンドでの更新プロセスが完了し、キャッシュが更新されたため、新しく投稿されたエントリを含む新しいコメント・リストがクライアントに返されます。
バックグラウンドの更新プロセスは、最初のリフレッシュとともに開始されます。2回目のリフレッシュでは、最初のリフレッシュの終了によってキャッシュが更新されているため、更新されたデータが表示されます。ただし、この処理はネットワークのオーバーヘッドや変更量によって影響を受けるため、2回より多くのリフレッシュが必要になる可能性があります。
デフォルトでは、Community-Gadgetsは標準キャッシュ・スキーマを使用します。パフォーマンスを向上させるには、スタンドアロン・フォルダ(デフォルトの場所は<cg_install_dir>/deploy/management/management_node1および<cg_install_dir>/deploy/production/production_node1)内の構成ファイルwsdk_facilities.propertiesで失効キャッシングを有効にします。そのためには、例83-1に示すapp_cache.staleプロパティをtrueに設定します。
例83-1 失効キャッシュ・モードの有効化
## Application cache facility configuration # + stale parameter enables usage 'old' data on production side # app_cache.stale=false
app_cache.staleプロパティをfalseに設定すると、標準キャッシング・スキーマが使用されます。ただし、製品の特定の領域では常に高い整合性レベルが必要になるため、次の領域では失効キャッシュ・モードが無視されます。
CommunityインタフェースおよびGadgetsインタフェース。管理を容易にするため、データは本番システムとの間で常に整合性が取れている必要があります。
訪問者のプロファイルに関する操作。特に、登録時にアプリケーションでは、同じ名前を持つユーザーが存在するかどうかを確認する必要があります。
キャッシュは「キャッシュ管理」コンソールを介して管理できます。このコンソールには、各Community-Gadgetsインスタンスのhttp://<cg_host:<cg_port/<cg_context/cacheからアクセスします。たとえば、http://mycosprod.example.com:8180/cg/cache/です。キャッシュ管理とCommunity-Gadgetsの詳細は、『Oracle Fusion Middleware WebCenter Sitesユーザーズ・ガイド』を参照してください。
キャッシングには、次のタイプの依存関係が関連付けられます。
コンテンツ変更の依存関係: このタイプの依存関係は、Commons Cacheなどのキャッシュ・エントリ表のDependencies列に記録されます。ここには、既存のアセットのIDが格納されます。関連付けられたアセットに変更があった場合、システムはこのキャッシュ・エントリを無効にします。
コンテンツ作成の依存関係: このタイプの依存関係はシステム固有です。このような場合、inCache依存関係キーワードのunknowndeps: <table name>というタイプが使用されます。表に新しいエントリが投稿されると、キャッシュは無効になります。このタイプのキャッシングは、なんらかの新しいコンテンツが投稿された場合に無効にする必要のある検索や個数の問合せで便利です。
キャッシュ管理中のユーザー操作は、Community-Gadgetsロジックと、キャッシュ内に格納されているエントリに常にマップされている必要があります。たとえば、コメントのロード中には、図83-5のデータ構造が、「コメント」ウィジェットのロード開始時に最初に表示される「ロード中」メッセージ(ロード操作)に関連付けられます。
次に、図83-5の手順を追った説明を示します。これらの手順では、コメントの各操作がどのように実行され、キャッシュされるかについて説明しています。
ディスカッション全体を集約するCommentFeedオブジェクトが検出されます。
コメントの総数が検出されます。この数を使用して、ページ操作のインタフェースおよび他のコメント関連の機能が計算され、レンダリングされます。
Community-Gadgetsで構成されているサイト設定がロードされます。これらの設定が、訪問者がアクセスしたページにレンダリングされるCommentFeedオブジェクトに適用されます。これらの設定によって、ページ上でコメント投稿フォームが表示される場所(上部または下部)、コメント投稿権限のレベルなどが決定されます。設定IDが検出された後、Community-Gadgetsはデータベースにアクセスする前にキャッシュを検索し、キャッシュ・ヒットを取得します。
サイトの設定がキャッシュされていない場合は、それらのIDを利用してWebCenter Sitesのリポジトリから設定をフェッチします。プロセスの効率性の観点から、可能なかぎりIDによる参照が使用されます。
Webサイトに表示される実際のコメントのロードが開始されます。Comment FeedオブジェクトとCommentRecordオブジェクトには1対多の関係があります。最初に、特定のフィードに関連付けられているすべてのコメントIDが検出されます。特定のフィードに関連付けられているコメントIDが検出された後、ローカルのキャッシュ・エントリとの間でIDが分析、検証されます。キャッシュ内に存在しないIDは次のリクエストでロードされます。
前の手順で検出されたIDを利用して、WebCenter SitesのリポジトリからCommentRecordオブジェクトがロードされます。
コメントが調べられ、認証済ユーザーによって投稿されたコメントから作成者IDが抽出されます。次に、WebCenter Sitesのリポジトリから、キャッシュ・ヒットが存在する訪問者のプロファイルIDがロードされます。
Community-Gadgetsのキャッシュ構成はWebCenter Sitesのキャッシュ構成と似ています。これは、いずれの製品も同じinCacheインフラストラクチャを使用しているためです。
キャッシュ構成ファイルcos-cache.xmlおよびcas-cache.xmlは、それぞれのCommunityノード・ディレクトリのcos-standalone-configディレクトリ内にあります。
このファイルの構成パラメータ、およびページ・キャッシュ用のinCacheの構成方法の詳細は、『Oracle Fusion Middleware WebCenter Sites管理者ガイド』を参照してください。
訪問者トラフィックとフィードバック量が最大になる、1日の中でのピーク時間帯があります。つまり、1日の中で、最大数のUGCエントリがデータベースに送信される時間帯があります。このようなピーク・ロード期間では、データベースは、訪問者がコンテンツ・エントリを送信する速度でコンテンツ挿入を処理できません。この状況を解消するため、WebCenter Sitesは遅延書込みというオプションを提供しています。これは、プロデューサ・コンシューマ・パターンを使用する単純で効果的なツールです。訪問者は、コメント、レビューなどの形式でシステムにコメントを送信します。その後、コンテンツ・エントリはデータベースのキューに入れられます。コンシューマ・スレッドはこれらのエントリをキューから選択して、1つずつデータベースに挿入します。そのため、これらの受信リクエスト(UGCエントリ)の結果は、後でWebサイトに表示されます。変更内容はバッファされてバックグラウンドで適用されるため、データの不整合が生じます。そのため、ユーザーは変更内容をすぐには表示できません。
遅延書込みオプションが使用できるのは、管理者がWebCenter Sitesで構成した後のみです。このオプションを有効にする方法の詳細は、第77章「WEMフレームワーク: バッファリング」を参照してください。Community-Gadgetsで使用されるWebCenter Sitesインスタンスに対して遅延書込みオプションが構成されたら、standalone_nodeフォルダ内にあるアプリケーションのsetup_cs.properties構成ファイルにもこのオプションを設定する必要があります(デフォルトの場所は<cg_install_dir>/deploy/management/management_node1および<cg_install_dir>/deploy/production/production_node1)。このファイルの中で、widgets.cs.production.attrs.delayed_writesプロパティをtrueに設定します。
# # Enabling "delayed writes" mechanism. CS will persist the assets asynchronously. # Default is "false" # widgets.cs.production.attrs.delayed_writes=true
Community-Gadgetsで遅延書込みオプションを有効にしたら、Communityの本番アプリケーション・サーバーと管理アプリケーション・サーバーを再起動します。訪問者がレビュー、コメントなどの形式でコンテンツを送信したときに、本番システムの動作が変わることがわかります。たとえば、訪問者がコメントを投稿すると、「送信ありがとうございます」メッセージが表示され、それがサーバー上で非同期で処理されないかぎり、コメントはサイトに表示されません。
