Spring Session Scoped Beanやehcacheなどのキャッシュを使用する必要がありますか？

Question

私たちは、（会話型の）対話でクライアント（ブラウザ）がデータを含むオブジェクト（潜在的にたくさん）を調べることができるように状態を維持する必要のあるアプリを持っています。要求ごとにデータをリロードするのは効率的ではありません。

私たちは、いくつかのセッション制御データを維持するためにSpringとセッションスコープBeanを使用します。しかし、これらの新しい豆はもっと大きくなります。

これはセッションスコープBeanの適切な使用ですか、キャッシュ（ehcache）が適していますか？

私たちが本当にする必要がない限り、キャッシング技術を採用することには消極的です。

もう1つの要因は、アプリをクラスタにデプロイする必要があることです。この場合、アプリケーションスコープのBeanはアプリケーションサーバーのセッションレプリケーションによって複製されるか、ehcacheを使用する方が効率的でしょうか（これはクラスタで分散できると思います）。

ご了承ください。この上の思考の

Answer 1

カップル（免責事項：私はテラコッタ/ ehcacheをのために働く...そう心の中でそれを保つ...それでもここに公平になろうとして）：

1 - のいずれかの冗長データがあります各セッションは？セッション間で共有できるものは何ですか？もしあれば、ehcacheが共有されたものを格納するために+1します（ehcacheは並行処理が最適化されているため）

2 - セッションオブジェクトの大きさはどれくらいですか？そして、あなたは安定した状態で何人の同時ユーザーを期待していますか？ （言い換えれば、アプリケーションサーバー上のセッションストレージにどれだけのメモリを割り当てる必要がありますか）

セッションフットプリントが全体的に大きくなく、GCの問題なしにヒープにうまく収まる場合は、セッションを使用します良い解決策でなければなりません。

しかし、それが大きくなるにつれ、Javaヒープが大きくなる必要があります。ガードコレクションとGC休止時間をチェックするためにブードゥー教のトリックを使用する必要があります。 ehcacheを使用すると、複数のセッションがアクセスできるオブジェクトを集中的に保存することができます。メモリのフットプリント（1と同じポイント）を統合します さらに、ehcache（BigMemory = http://terracotta.org/products/bigmemory）データをオフヒープに保存する必要があります（必要に応じて、10〜100GB以上）。これにより、メモリに格納する必要があるオブジェクトのサイズは無関係になります（サーバーにRAMを追加できる限り）

3 - セッションレプリケーションでは、JBOSS、Weblogic、Websphereなどのアプリケーションサーバーそれ。繰り返しますが、セッションサイズの問題です（ワイヤを介して複製する必要のあるデータ量）。セッションオブジェクトが大きく、それらのオブジェクトが多い場合、クラスタ全体で多くのネットワークトラフィックが発生します。うまく動作しない場合があります。 データ保管用に最適化された分散型EhCacheレイヤーにコアオブジェクトを置くことで、セッションを最小限に（ログイン/認証情報）維持することは、私の意見ではセッション複製メカニズムを確実に強化します。

希望に役立ちます。