25

InProc状態と比較してアプリでセッション状態をより堅牢にするためにSessionStateサーバーの使用を開始する前に、評価用の長所と短所のリストを見つけたいと思います。

更新1：存続するアプリケーションプールのリサイクルについても？

アップデート2：セッションの寿命とその終了についてはどうですか？

4

6 に答える 6

32

RobHowardのASP.NETSessionStateの記事から、3つのオプションの長所と短所の標準的な分析を次に示します。

  • 処理中です。セッション状態のメモリはASP.NETプロセス内に保持されるため、処理中は最高のパフォーマンスを発揮します。単一のサーバーでホストされているWebアプリケーションの場合、ユーザーが正しいサーバーにリダイレクトされることが保証されているアプリケーション、またはセッション状態データが重要ではない場合（再構築または再入力できるという意味で） 、これは選択するモードです。

  • プロセス外。このモードは、パフォーマンスが重要であるが、ユーザーがどのサーバーからアプリケーションを要求するかを保証できない場合に最適です。アウトプロセスモードを使用すると、メモリからの読み取りのパフォーマンスと、すべてのサーバーの状態を管理する別のプロセスの信頼性を得ることができます。

  • SQLServer。このモードは、データベースを障害シナリオ用にクラスター化できるため、データの信頼性がアプリケーションの安定性の基本である場合に最適に使用されます。パフォーマンスはプロセス外ほど高速ではありませんが、トレードオフはより高いレベルの信頼性です。

アウトプロセス（別名「StateServer」）とSQL-Serverオプションは、どちらもWebアプリケーションの再起動（アプリケーションプールのサイクリングを含む）に耐え、クラスター/ファーム内の複数のサーバーでセッションデータを利用できるようにします。

最後に、言うまでもありませんが、基本的なインプロセスセットアップは構成が最も簡単であり、多くの環境で意味のある「プロ」です。

Tim SneathのASP.NETセッション状態：アーキテクチャとパフォーマンスに関する考慮事項にいくつかの追加情報が追加されています。セッション状態モードに関するMSDNトピックは、信頼性の高い最新のソースです。

于 2010-04-26T14:41:03.700 に答える
6

State Serverは、始めるのに最適な（！）選択肢です。なんで？これは、アプリケーションがアウトプロセスストレージモードと互換性があることを意味します。

現在サイトを開発していて、後でInProc移行したいStateServer場合は、シリアル化で問題が発生する可能性があります。SqlServer常にではありませんが、実際に起こります。

いくつかの例が含まれます（いくつかはすでに述べました）：

  • Opsは、知らないうちに定期的なIISアプリケーションプールのリサイクルのスケジュールを開始します
  • 定期的にメモリが不足しています
  • あなたは本番環境でロードバランサーを使用することになり、同じWebサイトが同じリクエストを受け取ることを保証することはできません。

したがって、これを後でではなく早く整理するのが最善です。構成の変更とサービスの開始のみです。ブーム！

また、Redis（分散キー/バリューストア）やRavenDB（ドキュメントデータベース）を使用するなど、セッションストレージのまったく異なるルートを使用する場合は、既に並べ替えられています。

それは本当に1分の作業の良い投資です。これで、Webファーム、ロードバランサー、およびプロトタイプを作成することを決定したその他のセッション管理システムの準備が整いました。

于 2014-07-11T08:05:12.603 に答える
5

In_Procを使用することの大きな欠点の1つは、アプリプールまたはドメインをリサイクルするとセッション状態が失われる可能性があることです。これは、たとえばサーバーのメモリが不足している場合など、いつでも発生する可能性があります。私は個人的に、失いたくないものをIn_Procセッションに依存することはありません。散発的な問題のあるサイトのデバッグに何時間も費やしましたが、それはリソースのリサイクルが少ないサーバーが原因でセッション状態が失われていたためです（もちろん、セッションに保存する量が多いほど、サーバーリソースも少なくなります）使い切ることを忘れないでください。うまくいかない場合は、ある時点でうまくいかない可能性があります。

そのため、私は通常、些細なセッションデータ以外の目的でStateServerを使用しています。私が見つけた唯一の本当の欠点は、クラスをシリアル化可能としてマークする必要があることですが、これは通常は些細なことです。また、少し遅くなりますが、ほとんどの場合、それは無視できます。

IISのMSDNブログに、これに関する優れた記事があります。

于 2010-04-26T15:13:48.280 に答える
4

利点：
1。マシン間で同じセッション状態にアクセスできます。
2. app_poolをリロードした後、同じセッション状態が使用可能になります。

短所：
1。プロセスモードよりも遅くなります。
2.セッション状態のすべてのオブジェクトは、シリアル化可能である必要があります。

于 2010-04-26T14:37:53.880 に答える
4

ASP.NETのセッションのデメリット

  • すべての変数はオブジェクトとして保存されます。つまり、セッション変数を読み取るときに、オブジェクトを特定のタイプに変換する必要があります。

  • これに加えて、セッションが空の場合、オブジェクトはnullになります。セッション変数を読み取る前に、nullをチェックする必要があります。変数が以前に初期化されていても、セッションの有効期限が切れているため、nullになる可能性があります。nullセッション値を使用しようとすると、例外が返される可能性があります。セッション変数の値がnullの場合、一般的な方法は、意味のないnullではなくデフォルト値を使用することです。値がnullでない場合、すべてのセッション変数はオブジェクトの型であるため、適切な型に変換する必要があります。これらすべてを行うときは、ハードコーディングを避けるように注意する必要があります。セッション状態変数の書き込み、読み取り、削除の方法のチュートリアルで、スケーラブルで保守可能な方法でのセッション変数の読み取りと書き込みについて詳しく説明します。

  • 変数名は文字列のタイプです。変数の名前をハードコードする場合、どこかでタイプミスをするオプションがあります。問題は、存在しないセッション変数を読み取ろうとしても、ASP.NETが例外や警告を返さないことです。null値を持つ間違った名前の新しい変数を作成するだけです。これらのタイプのエラーは見つけるのが難しい場合があります。

  • セッションデータは、機密データの保存には使用しないでください。悪意のあるユーザーが通常の訪問者のセッションIDを取得する可能性があります。セッション状態を使用して「管理領域へのアクセスを許可するかどうか」などの情報を保存すると、攻撃者はWebサイトの機密データ、他者の個人データの閲覧、データベースの編集、コンテンツの削除などを行う可能性があります。

  • InProcモードを使用すると、セッションによってすべてのサーバーリソースが簡単に使い果たされ、Webサイトのパフォーマンスが低下します。

StateServer

SQL Serverは、すべてのモードの中で最も信頼性があります。ASP.NETが再起動した場合だけでなく、SQL Serverが再起動した場合も、セッションデータはそのままです。

SQLServerも最もスケーラブルなオプションです。

SQL Serverは、多くの場合、共有ホスティングシナリオで利用できます

カスタムモード

セッションを完全に制御できます。カスタムセッションIDも作成できます。

さまざまなデータソースをサポートできます。これは、Oracle、MySQL、MSAccessなどの他のデータベースにセッションデータを保存するのに役立つ可能性があります。

その他の詳細については、ここをクリックしてASP.NETセッション状態の利点を確認できます。私の答えがお役に立てば幸いです。:)

于 2015-01-21T04:39:59.883 に答える
0

他の1つの欠点は、ファーム全体で1つのリモート状態サーバーを実行すると、おそらく単一障害点が発生することです。ファームでなくても、app_poolIMOを生き残るためだけにローカルで実行する価値はあります。シリアライズ可能な部分に巻き込まれたので、それを見てください。

また、Windows Server AppFabricのリリースに注意してください。これは、複製/分散状態サーバーの代替品となるためです。おそらく2010年上半期のRTM。

于 2010-04-26T14:49:15.277 に答える