ASP .NET / MVC C# 3.5 Web アプリの状態管理戦略を考え出すように依頼されました。
私は状態サーバーにセッションを保存することを選択しました - これは別の物理的なボックスになります。セッションに保存するときにオブジェクトをシリアライズ/デシリアライズするのにかかる時間が心配です...
これを行うときに最大のパフォーマンスを得るためのテクニックを知っている人はいますか?
また、情報をセッション ヘルプに格納する前に圧縮するなどの処理を行うか、これによりパフォーマンス時間が遅くなります。
編集: 複数の Web サーバーがあるため、状態サーバー用に別のボックスを使用しています。
個人的には、ここで最も一般的な要素は、セッションに入れる情報の量を減らすことです。
圧縮はスペースを節約する可能性がありますが、それを実行するにはより多くの CPU 時間がかかり、パフォーマンスが低下するか、少なくとも正味の利益が得られない可能性が高くなります。本当に大きなオブジェクトについて話している場合を除きます。
ここ StackOverflow で使用されている、セッション、アプリケーション、およびキャッシュでの Zip 圧縮の例。
セッション状態を使用しないページでは必ず無効にしてください。「既定では、ASP.NET セッション状態マネージャーは、要求されたページがセッション状態を使用しているかどうかに関係なく、すべての要求でセッション データ ストアに対して 2 つのアクセス (1 つの読み取りアクセスと 1 つの書き込みアクセス) を実行します。」--MSDN マガジン
ソリューションを時期尚早に最適化しようとしていないことに注意してください。セッション圧縮のようなものを実装する前に、一連のベンチマークを実施して、そのようなものがアプリケーションに必要かどうかを判断することをお勧めします。
そんなに多くのデータをセッション ストレージに保存するつもりですか? 1 人のユーザーのセッションの一般的な使用量は、数百バイトです。
連載と脱連載に関しては、それでちょっと小さいサイズは無視できます。
もちろん、それよりも多くのユーザーが期待されますが、それでもなお.
セッションに大量のデータを保存している場合、IMO、間違っています。
ユーザーごとのセッション状態のデータが多すぎるのは問題の兆候であると指摘する人もいますが、その解決策を直接指摘していません。ユーザー SQL データベースを保持し、そこにすべてのユーザー情報を保存します。次に、セッション状態は通常、ログインしているユーザーの ID だけで構成されます。他の状態は、おそらくユーザーの現在のアクティビティに直接関連している可能性があり、メモリ内 Cookie またはクエリ文字列変数としてより適切に保持できる可能性があることを示唆しています。多くの場合、ユーザーが [戻る] ボタンと [進む] ボタンをクリックすると、物事が破損した状態になるため、とにかくこれがより良いオプションです。