今まで、HTTPセッションを使う中で、考えていた事
何か謎のメモ書きを見つけたので、余り深く考えずにそのままエントリにしてしまう事にした。
そもそも、HTTPの上でステートフルなアプリケーションを作ろうとする事自体に、
一定の矛盾がある事を忘れてはいけない。
HTTP以外の方法使ってもイイんなら、そっちの方が良いケースの方が多いよ。
ほんとにステートフルアプリケーションなの？
ステートレスなアプリケーションじゃないの？
んで、ステートは、サーバで持つの？クライアントで持つの？
HTTPを使わざるをえず、ステートフルアプリケーションであり、
ステートはサーバで抱えるなら、HTTPセッションだよね、って話。
で、正しい答えは分らないのだけど、大体いつもこんな感じの事を考えてる。
- 最大でどの程度の量の情報を抱えるのか？
- シリアライズ化コスト
- レプリケーション*1
- ロードバランシング(クラスタリング)
- 「WebサーバとAPサーバ」みたいな構成にするかどうか。
- 「ハードウェア増設する条件と頻度と計画」的な話
- 無効化のタイミング
- 負荷の傾向
- 最大/最低同時アクセス数/日
- 最大/最低ユニークユーザ数/日
- 負荷の極端なばらつきが無いか？
- プロセスの再起動は可能な構成にしてあるか？
まぁ、何か色んなモノがごっちゃになってるし、何か抜けてる感がさもありなん。
あんま難しい事考えなくても、メモリイッパイ積めば、いいじゃんって話も忘れない様に。
64bit対応OSなら、ﾃﾗﾊﾞｲﾄ単位で積めるよ？ﾏｼﾞﾃﾞﾒﾓﾘﾃﾗﾂﾒﾙｽ。
普通のブレードサーバでも、32ｷﾞｶﾞﾊﾞｲﾄとか積めるよ？
でも、メモリ積み過ぎると、FullGC怖いよ？忘れないデ。
CPUイッパイあるからって、GCが速いとは限らないよ。
場合によっては、遅くなるかもしれない。
あんまし真面目にテストした事無いし、
手元にそういう資料が無いのでホントの事は分からないケドネ。
後ね、デカいハードを仮想化して、小さいサーバを沢山ならべる構成にした方が、
パフォーマンスが出るアプリケーションもあるかもよ。
