（InProcの代わりに）ASP.NET Session State Serverを使用することの長所と短所？
InProc状態に比べてアプリのセッション状態をより堅牢にするためにセッション状態サーバーの使用を開始する前に、評価のための長所と短所のリストを見つけたいと思います。
pdate 1：残っているアプリケーションプールのリサイクルについても教えてください。
アップデート2：セッションの寿命とエンディングについてはどうですか？
Rob Howardの ASP.NETセッション状態 の記事から、3つのオプションの長所と短所の標準的な分析を次に示します。
処理中。セッション状態のメモリはASP.NETプロセス内に保持されるため、インプロセスは最高のパフォーマンスを発揮します。単一サーバーでホストされているWebアプリケーションの場合、ユーザーが正しいサーバーにリダイレクトされることが保証されているアプリケーション、またはセッション状態データが重要でない場合（再構築または再入力できるという意味で） 、これは選択するモードです。
アウトプロセス。このモードは、パフォーマンスが重要な場合に最適ですが、ユーザーがアプリケーションをリクエストするサーバーを保証することはできません。アウトプロセスモードでは、メモリからの読み取りのパフォーマンスと、すべてのサーバーの状態を管理する個別のプロセスの信頼性が得られます。
SQL Server。このモードは、データの信頼性がアプリケーションの安定性の基本である場合に最適です。データベースは障害シナリオに合わせてクラスター化できるためです。パフォーマンスはアウトプロセスほど高速ではありませんが、トレードオフはより高いレベルの信頼性です。
アウトプロセス（ "StateServer"とも呼ばれます）とSQL-Serverのオプションは、どちらもWebアプリケーションの再起動（アプリケーションプールの循環を含む）後も存続し、クラスター/ファーム内の複数のサーバーでセッションデータを利用できるようにします。
最後に、言うまでもありませんが、基本的なインプロセスセットアップが最も簡単に構成できます。これは、多くの環境で意味のある「プロ」です。
Tim Sneathの ASP.NETセッション状態：アーキテクチャとパフォーマンスに関する考慮事項 はいくつかの追加情報を追加します セッション状態モードに関するMSDNトピック は信頼できる最新のソースです。
State Serverはgreat（！）で始めるための選択肢です。どうして？これは、アプリケーションが任意のアウトプロセスストレージモードと互換性を持つようになったためです。
現在、InProcを使用してサイトを開発していて、後でStateServerまたはSqlServerに移動したい場合は、シリアル化で問題が発生する可能性があります。常にというわけではありませんが、実際に起こります。
いくつかの例が含まれます（いくつかは既に言及されています）：
- Opsは定期的なスケジュールを開始しますIISアプリケーションプールのリサイクルは知らないうちに
- メモリが定期的に不足しています
- あなたは本番環境でロードバランサーを使用し、同じWebサイトが同じリクエストを受信することを保証できません。
したがって、後で整理するよりも早く整理するのが最善です。その唯一の構成変更とサービス開始。ブーム！
また、Redis（分散キー/バリューストア）やRavenDB（ドキュメントデータベース）を使用するなど、セッションストレージのまったく異なるルートを使用する場合、すでにソートされています。
それは本当に1分の仕事の良い投資です。これで、プロトタイプを作成することを決定したWebファーム、ロードバランサー、およびその他のセッション管理システムの準備が整いました。
利点：
1。マシン間で同じセッション状態にアクセスできます。
2。 app_poolを再ロードすると、同じセッション状態が利用可能になります。
短所：
1。プロセスモードよりも遅くなります。
2。セッション状態のすべてのオブジェクトはシリアル化可能である必要があります。
In_Procを使用することの大きな欠点の1つは、アプリプールまたはドメインがリサイクルされるとセッション状態が失われる可能性があることです。これはいつでも発生する可能性があります。たとえば、サーバーのメモリが不足している場合などです。個人的に、In_Procセッションに依存したくないものは一切使用しません失う。散発的な問題のあるサイトのデバッグに何時間も費やしてきましたが、それは、サーバーのリソースのリサイクルが少ないためにセッション状態が失われていたためです（もちろん、セッションに多く保存するほど、サーバーリソースが少なくなります。それがうまくいかない場合は、おそらくどこかでうまくいかないでしょう！
だからこそ、今では通常、些細なセッションデータ以外の目的でState Serverを使用しています。私が見つけた唯一の本当の欠点は、クラスをシリアル化可能としてマークする必要があることですが、これは通常は取るに足らないことです。それも少し遅いですが、ほとんどの場合それは無視できます。
IIS MSDNブログに これに関する良い記事 があります。
ASP.NETでのセッションの欠点
すべての変数はオブジェクトとして保存されます。つまり、セッション変数を読み取るときにオブジェクトを特定の型に変換する必要があります。
これに加えて、セッションが空の場合、Objectはnullになります。セッション変数を読み取る前に、それがnullかどうかを確認する必要があります。変数が以前に初期化されている場合でも、セッションの有効期限が切れているためnullになる可能性があります。 nullセッション値を使用しようとすると、例外が返される可能性があります。セッション変数の値がnullの場合、一般的な方法は、意味のないnullではなく、いくつかのデフォルト値を使用することです。値がnullでない場合は、すべてのセッション変数がオブジェクトのタイプであるため、適切なタイプに変換する必要があります。このすべてを行うときは、ハードコーディングを回避するように注意を払う必要があります。セッション状態変数の書き込み、読み取り、削除の方法のチュートリアルで、スケーラブルでメンテナンス可能な方法でセッション変数を読み書きする方法の詳細。
変数名は文字列のタイプです。変数の名前をハードコードする場合、どこかでタイプミスをするオプションがあります。問題は、存在しないセッション変数を読み取ろうとした場合、ASP.NETが例外や警告を返さないことです。 null値を持つ間違った名前の新しい変数を作成するだけです。これらのタイプのエラーは見つけにくい場合があります。
機密データの保存にセッションデータを使用しないでください。悪意のあるユーザーが通常の訪問者のセッションIDを取得する可能性があります。 「管理領域へのアクセスを許可するかどうか」などの情報を保存するためにセッション状態が使用されている場合、攻撃者はWebサイトの機密データ、他人のプライベートデータの表示、データベースの編集、コンテンツの削除などを行う可能性があります。
InProcモードを使用すると、セッションがすべてのサーバーリソースを簡単に使い果たし、Webサイトのパフォーマンスが低下します。
StateServer
SQL Serverは、すべてのモードの中で最も信頼性があります。 ASP.NETが再起動しても、SQL Serverが再起動しても、セッションデータは変わりません。
SQL Serverも最もスケーラブルなオプションです。
SQL Serverは多くの場合、共有ホスティングシナリオで利用できます
カスタムモード
セッションを完全に制御できます。カスタムセッションIDを作成することも可能です。
さまざまなデータソースをサポートできます。これは、Oracle、MySQL、MS Accessなどの他のデータベースにセッションデータを保存するのに役立ちます。
その他の詳細については、 ここをクリックしてASP.NETセッション状態の利点を確認してください 。私の答えがお役に立てば幸いです。 :)
もう1つの欠点は、ファーム全体で1つのリモートステートサーバーを実行すると、シングルポイント障害が発生する可能性があることです。ファームでなくても、app_pool IMOを生き残るためにローカルで実行する価値はまだあります。シリアライズ可能な部分に追いついたので、それを見てください。
また、Windows Server AppFabricのリリースに注意してください。複製された/分散状態のサーバーに置き換わるためです。おそらくRTM 2010年上半期。