- PR -

セッションに登録された大量データを削除するタイミング

投稿者投稿内容
taro
ぬし
会議室デビュー日: 2003/10/20
投稿数: 316
投稿日時: 2004-02-10 11:13
自分は逆に、セッションにデータを持たせる方法で構築しました。
最大同時ログイン数や最大データ件数、待ち時間の最大数などの
要件が決まっていて、それに耐えうるインフラが用意できれば
特に問題はないと思いますが、いかがでしょうか?
(クラスタリングで無限に増強できるイメージを持っていますが、
 はずしているでしょうか?)
タモリのファン
会議室デビュー日: 2004/02/07
投稿数: 7
投稿日時: 2004-02-10 11:36
引用:

(クラスタリングで無限に増強できるイメージを持っていますが、
 はずしているでしょうか?)


セッションが大きい場合は、クラスタリングすればするほど
負荷が上がる場合もあるのかなーってちょっと思った。
教えて、詳しい人!
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷        良回答(20pt)
投稿日時: 2004-02-10 11:40
unibon です。こんにちわ。

引用:

顔爺さんの書き込み (2004-02-10 10:27) より:
java.lang.ref.SoftReference を利用するのはいかがでしょうか。
SoftReference を利用すれば、OutOfMemoryError が発生する前に gc される
ことが保証されるメモリキャッシュを実装できます。


SoftReference の仕様は、細かなアルゴリズムまでは規定していないこともあり、これを以前に Sun Java の 1.4 で試しに使ってみたことがありますが、キャッシュは全部残るか全部消えるかの2つに1つであり、LRU などのようなロジックは実装されていないようでした。しかし、SoftReference さえ使えば、アプリケーションでキーだけを決めれば、その他のキャッシュのロジックをほとんど考える必要がなく手軽に使えて、メモリを圧迫しないことが保証されているのは便利です。
ただ、キャッシュは凝るといくらでも複雑なロジックが考えられるため、ヘタに手を出すとバグなどが潜む可能性が出てくるため、大変です。キャッシュがメインではないアプリケーションならば、毎回 SQL を投げて、DBMS 関連のキャッシュだけに期待するほうが良いかもしれません。
taro
ぬし
会議室デビュー日: 2003/10/20
投稿数: 316
投稿日時: 2004-02-10 11:59
タモリのファンさま

>セッションが大きい場合は、クラスタリングすればするほど
>負荷が上がる場合もあるのかなーってちょっと思った。
>教えて、詳しい人!

自分は詳しいわけではありませんが、@ITさまの以下の記事によると、
クラスタリングの方法などによって、かえって遅くなるケースもあるようですね。

連載:J2EEパフォーマンスチューニング 第3回 APサーバのチューニング項目を知る
http://www.atmarkit.co.jp/fjava/rensai/j2eeprfm03/j2eeprfm03_6.html
クラスタ化すると遅くなる?― HttpSessionへの積み過ぎに注意 ―
http://www.atmarkit.co.jp/fjava/rensai2/webopt01/webopt01.html

自分の場合は、挙げられた事例とはクラスタリングの方法が違うこともありますが、
レスポンスの低下は発生しませんでした。
本来の話題から外れた投稿をしてしまい、申し訳ございません。
おばけ
ぬし
会議室デビュー日: 2002/11/14
投稿数: 609
お住まい・勤務地: 東京都江東区
投稿日時: 2004-02-10 12:09
引用:

セッションが大きい場合は、クラスタリングすればするほど
負荷が上がる場合もあるのかなーってちょっと思った。


APサーバをクラスタ化すると、HttpServletセッションのデータを複数のAPサーバ間で
レプリケートする必要が生じます。その際は、一般にHttpServletセッション内の
Javaオブジェクトをシリアライズし、バイナリデータとしてネットワーク経由で
転送するのが一般的だと思われます。

この場合、レプリケート対象のデータが多ければ多いほど、ネットワークでの転送時間が
長くなりますし、オブジェクトのシリアライズ/デシリアライズに掛かる時間も長く
なります。また、通常このオブジェクト転送はクライアントへのサービスを行うサービス系の
ネットワークで行われますので、サービス系の帯域をたくさん使ってしまうという
弊害も生じます。

また、HttpServletセッションは通常はオンメモリで保持されることが多いと思われますので、
大量のHttpServletセッションデータがAPサーバのインスタンスのヒープ領域を圧迫する
という点でも好ましくありません。

まとめると以上のような感じでしょうか。
タモリのファン
会議室デビュー日: 2004/02/07
投稿数: 7
投稿日時: 2004-02-10 13:44
taroさん、参考リンクありがとう。すごく勉強に成りました(著者さんもありがとう)。

おばけさん、解説分かり易いです。ありがとう。

お金があるなら、安易にクラスタ化すれば良いと言うわけでは無いのですね。
逆に、クラスタ化する可能性がある場合は、設計段階で考慮しなければなら
ないのですね。肝に銘じておきます。
おばけ
ぬし
会議室デビュー日: 2002/11/14
投稿数: 609
お住まい・勤務地: 東京都江東区
投稿日時: 2004-02-10 14:04
引用:

お金があるなら、安易にクラスタ化すれば良いと言うわけでは無いのですね。


えと、クラスタ化というのは一般的に性能と可用性の二つの側面から語られると思います。

処理性能を上げるという点から言えば前者ですが、この場合はクラスタ化による
スケーラビリティが問題になってきます。簡単に考えても、クラスタのノード(単体の
コンピュータ)が複数結合した場合、今回のセッションレプリケーションの様にノード
間通信は必須で発生します。その場合、ノード単体では発生しない処理が追加される
わけですから、当然ノード数が2倍になってもクラスタ全体での処理性能が2倍には
なりません。

処理にもよりますが、例えば8ノードくらいで処理性能の向上が頭打ちになってしまう
(つまりノードを幾ら追加しても処理性能が上がらない、もしくは下がってしまう)状態に
陥るものもあります。

クラスタ化する場合のポイントは、常に
「ノード追加による処理の増加」<<「ノード追加による性能の向上」
を見極めて設計を行うことだと思います。
佐々木
大ベテラン
会議室デビュー日: 2003/03/30
投稿数: 121
投稿日時: 2004-02-10 14:24
なんか世の中に「セッションにものをぶら下げるのは悪」みたいな過剰な認識が広まっている気がしますが。

普通にキャパプラして大丈夫そうなら使えばよいしダメなら他の方法を考えればよいでしょう。

先日知人に聞いたのですが、「セッションを使うとメモリを圧迫するので、セッションIDをキーにしたHashMapにデータを格納してます」なんて言う人がいるみたいですね。

やってることは同じだと思うんですけど。

[ メッセージ編集済み 編集者: サ 編集日時 2004-02-10 14:26 ]

スキルアップ/キャリアアップ(JOB@IT)