WebSphere Application Server Network Deployment, Version 6.1   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows, Windows Vista

             目次と検索結果のパーソナライズ化

キャッシュ複製

複製では、データを生成するのは 1 度で、生成したデータをクラスター内の他のサーバーにコピー、 つまり複製するので、時間とリソースを節約することができます。 クラスターでのキャッシングには、これ以外にも懸案事項があります。 特に、同一データが要求される場合があり、 同一のデータが複数の場所に生成されることがあります。 また、キャッシュ・データを生成するリソースに必要な許可が制限されて、 データへのアクセスが妨げられることもあります。

キャッシュを複製すれば、データの生成は 1 度で済み、 クラスター内の他のサーバーにそれをコピーすることにより、こうした問題に対処することができます。 また、キャッシュの整合性も保つことができます。不要なキャッシュ・エントリーは、除去または置き換えられます。

データ複製の構成は、 管理コンソールから利用できる Web コンテナーの動的キャッシュ構成の一部として行うか、 または cachespec.xml ファイルを介してキャッシュ・エントリーごとに行うことができます。 cachespec.xml ファイルを使用して、 キャッシュの複製を、Web コンテナー・レベルで構成することも、 特定のキャッシュ・エントリーに対して使用不可にすることもできます。

キャッシュの複製には、以下の 3 つの形式があります。

動的キャッシュ・サービスはキャッシュ複製の更新を、作成されるとすぐに送信するのではなく、構成可能なもの (動的キャッシュ・サービスの管理コンソール・パネルでの更新間隔のバッチ) に基づいて非同期でブロードキャストします。失効は即時に送信されます。失効の配布は、失効したデータがクラスター内に常駐することを防止します。 キャッシュ複製の構成について詳しくは、 キャッシュ複製の構成 および動的キャッシュ・サービスの設定 を参照してください。

重要: PUSH/PULL モードでは、 キャッシュ・オブジェクトは、それを作成したサーバーにローカルで保持されますが、 他のサーバーもキャッシュ ID を使用して、 そのオブジェクトを DRSPushPullTable テーブルに保管します。 リモート・サーバーは、オブジェクトを必要とする場合には、 キャッシュ ID、または名前によって、 そのオブジェクトを作成するサーバーから要求します。 各キャッシュ・インスタンスには、 そのインスタンスに関連付けられた DRSPushPullTable テーブルが 1 つあります。 以下のような条件では、DRSPushPullTable テーブルが極端に大きくなります。
問題を解決するには、以下の作業を行うことをお勧めします。
  • 可能であれば、ヒープ・サイズを 1.5 GB または 2 GB に増やす。
  • エントリーの有効期限の時間について、より適切な分散を保つようにする。 例えば、以下のようにします。
    • エントリーの 20% は、有効期限を定めない。
    • エントリーの 30% は、3600 秒で有効期限が切れるようにする。
    • エントリーの 30% は、600 秒で有効期限が切れるようにする。
    • エントリーの 20% は、60 秒で有効期限が切れるようにする。
  • WebSphere Application Server V6.1 で、 ディスク・オフロード・フィーチャーを使用する場合は、 ディスク・キャッシュのパフォーマンス設定 (ロー、バランス、 およびカスタム) に対して、 ディスク・クリーンアップの頻度を最適な値 (分単位) に調整します。 例えば、エントリーの 約 20% を、その時点で有効期限が切れるようにします。



関連タスク
キャッシュ複製の構成
関連資料
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 7:44:53 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/cdyn_cachereplication.html