キャッシュ複製
複製では、データを生成するのは 1 度で、生成したデータをクラスター内の他のサーバーにコピー、 つまり複製するので、時間とリソースを節約することができます。 クラスターでのキャッシングには、これ以外にも懸案事項があります。 特に、同一データが要求される場合があり、 同一のデータが複数の場所に生成されることがあります。 また、キャッシュ・データを生成するリソースに必要な許可が制限されて、 データへのアクセスが妨げられることもあります。
キャッシュを複製すれば、データの生成は 1 度で済み、 クラスター内の他のサーバーにそれをコピーすることにより、こうした問題に対処することができます。 また、キャッシュの整合性も保つことができます。不要なキャッシュ・エントリーは、除去または置き換えられます。
データ複製の構成は、管理コンソールから利用できる Web コンテナーの動的キャッシュ構成の一部として行うか、または cachespec.xml ファイルを介してキャッシュ・エントリーごとに行うことができます。cachespec.xml ファイルを使用して、キャッシュの複製を、Web コンテナー・レベルで構成することも、特定のキャッシュ・エントリーに対して使用不可にすることもできます。
キャッシュ複製は、複数のサーバントが使用可能になっている基本サーバー上、
あるいはクラスター環境にあるサーバー上で、構成することができます。
クラスター環境でキャッシュ複製を使用可能にすると、
クラスター内の 1 つのサーバーだけがアクティブになっている場合でも、
すべてのサーバント間で複製が行われます。
- PUSH - 新規エントリー (ID とデータの両方) を送信し、これらのエントリーに対する更新を行う。
- PULL - データがローカルに存在しない場合に、クラスター内の他のサーバーからのデータを要求する。 この複製モードはお勧めしません。
- PUSH/PULL - 新規エントリーの ID を送信し、クラスター内の、 以前 ID をブロードキャストした他のサーバーからのみデータを要求する。 動的キャッシュは、常にキャッシュ・エントリーの失効を送信します。
バッチ更新を実行することもできます。特に、PUSH および PUSH/PULL の場合、動的キャッシュは更新を作成時時にすぐに送信するのではなく、定期的に非同期でブロードキャストします。失効は即時に送信されます。失効の配布は、失効したデータがクラスター内に常駐することを防止します。 キャッシュ複製の構成について詳しくは、 キャッシュ複製の構成および動的キャッシュ・サービスの設定を参照してください。
- 他のサーバーで共有されるエントリー数が非常に多い。
- 期限切れになっているエントリーが少ない。
- ディスク・オフロード・フィーチャーを使用しているのに、 期限切れのエントリーを除去するディスク・スキャンが 頻繁に実行されていない。
- 可能であれば、ヒープ・サイズを 1.5 GB または 2 GB に増やす。
- エントリーの有効期限の時間について、より適切な分散を保つようにする。
例えば、以下のようにします。
- エントリーの 20% は、有効期限を定めない。
- エントリーの 30% は、3600 秒で有効期限が切れるようにする。
- エントリーの 30% は、600 秒で有効期限が切れるようにする。
- エントリーの 20% は、60 秒で有効期限が切れるようにする。
- WebSphere® Application Server 7.0 で、 ディスク・オフロード・フィーチャーを使用する場合は、ディスク・キャッシュのパフォーマンス設定 (ロー、バランス、 およびカスタム) について、ディスク・クリーンアップの頻度を最適な値 (分単位) に調整します。 例えば、エントリーの 約 20% を、その時点で有効期限が切れるようにします。