WebSphere® Application Server にデプロイされた Java EE アプリケーションでは、動的キャッシュ API を使用できます。 動的キャッシュを使用して、ビジネス・データや生成された HTML をキャッシュに入れたり、データ複製サービス (DRS)を使用してセル内のキャッシュ・データを同期化したりすることができます。
WebSphere eXtreme Scale 動的キャッシュ・プロバイダー で作成されたすべての動的キャッシュ・インスタンスは、デフォルトで、高い可用性を持ちます。高可用性のレベルおよびメモリー・コスト は、使用されるトポロジーによって変わります。
組み込みトポロジーを 使用している場合、キャッシュ・サイズは、1 つのサーバー・プロセス内の空きメモリー の量に制限され、各サーバー・プロセスはキャッシュの完全コピーを 保管します。1 つのサーバー・プロセスが実行し続けている限り、 キャッシュは存続します。キャッシュ・データが失われるのは、 キャッシュにアクセスするすべてのサーバーがシャットダウンされた場合のみです。
組み込み 区画化トポロジーを使用するキャッシングの場合、キャッシュ・サイズの上限は、すべてのサーバー・プロセス内 にある空きスペースの総計です。デフォルトでは、eXtreme Scale 動的キャッシュ・プロバイダー は各プライマリー断片ごとに 1 つのレプリカを使用します。したがって、各キャッシュ・データは 2 回ずつ 保管されます。
組み込み区画化キャッシュの容量を判定する には、以下の式 A を使用してください。
式 A
F * C / (1 + R) = M
各プロセスに 256 MB の使用可能なスペースがあり、サーバー・プロセスが合計 4 つある WebSphere Application Server Network Deployment データ・グリッド の場合、それらの全サーバーにまたがるキャッシュ・インスタンスは 512 メガバイトまでのデータを 保管できます。このモードでは、キャッシュ は、1 つのサーバーが破損しても、データを失うことなく存続できます。また、最大 2 つのサーバーが 順次シャットダウンしても、データを失うことは ありません。この例では、上の式は次のようになります。
256mb * 4 コンテナー/ (1 プライマリー + 1 レプリカ) = 512mb
リモート・トポロジーを使用するキャッシュのサイジング特性は、組み込み区画化トポロジーを 使用するキャッシュと似ていますが、 すべての eXtreme Scale コンテナー・プロセス内の使用可能なスペースの総量に制限されます。
リモート・トポロジー では、レプリカの数を増やすことによって、メモリーのオーバーヘッドが余分にかかる代わりにアベイラビリティーのレベルを上げることが 可能です。これは大部分の動的キャッシュ・アプリケーションでは不必要ですが、 dynacache-remote-deployment.xml ファイルを編集してレプリカの数を 増やすことができます。
以下の式 B と C を使用して、 キャッシュの高可用性のためにレプリカを追加することの影響を 判定できます。
式 B
N = Minimum(T -1, R)
式 C
Ceiling(T/ (1+N)) = m
動的キャッシュ・プロバイダーでのパフォーマンス・チューニングに ついては、動的キャッシュ・プロバイダーのチューニングを参照してください。
WebSphere eXtreme Scale 動的キャッシュ・プロバイダー を使用するアプリケーションをデプロイする前に、前のセクションに記述されている一般的な規則に、 実動システムの環境データを組み合わせて検討する 必要があります。まず最初に確定する必要がある数値は、コンテナー・プロセスの総数と、 キャッシュ・データを保持するための各プロセス内の使用可能メモリーの量 です。組み込みトポロジーを使用している場合、 キャッシュ・コンテナーは WebSphere Application Server プロセスの内部の同一場所に配置 され、キャッシュを共有する各サーバーごとにコンテナーが 1 つずつある状態になります。 キャッシングを使用可能にしていないアプリケーションと WebSphere Application Server の メモリー・オーバーヘッドを判定することが、プロセス内で使用可能なスペース量を 計算する最良の方法です。これは、詳細ガーベッジ・コレクション・データを分析することで 行えます。リモート・トポロジーを使用している場合、この情報は、 新しく開始され、キャッシュ・データがまだ設定されたことのないスタンドアロン・コンテナーの、詳細ガーベッジ・コレクション出力 を見れば分かります。 キャッシュ・データ用に使用可能な、プロセス当たりのスペース量を計算する 際には、ガーベッジ・コレクション用にいくらかのヒープ・スペースを確保 しておくことにも注意が必要です。コンテナー (WebSphere Application Server または スタンドアロン) のオーバーヘッドに、キャッシュ用に予約されたサイズを加えた結果は、 合計ヒープの 70 % 以下になっているべきです。
この情報を収集できたら、 前述の式 A に値を挿入して、区画化されたキャッシュの 最大サイズを判定してください。最大サイズが判明したら、 次のステップは、サポートできるキャッシュ・エントリー総数を 判定することです。これには、キャッシュ・エントリー当たりの平均サイズを 決定することが必要です。これを行う簡単な方法は、カスタマー・オブジェクトのサイズに 10% 追加 することです。動的キャッシュを使用している場合のキャッシュ・エントリーのサイズ見積もりについて詳しくは、動的キャッシュおよびデータ・レプリカ生成サービスのチューニング・ガイドを参照してください。
圧縮が有効に されている場合、圧縮はカスタマー・オブジェクトのサイズには影響しますが、キャッシング・システムのオーバーヘッドには影響しません。 圧縮を使用している場合のキャッシュ・オブジェクトのサイズを 判定するには、以下の式を使用します。
S = O * C + O * 0.10
次に、この情報を 使用して、サポートできるキャッシュ・エントリーの総数を判定します。以下の式 D を 使用してください。
式 D
T = S / A
式 E
Cs = Ts / Np