8

StateServer または SQLServer?

  • ASP.NET セッション変数を格納するための最適なソリューションは何ですか?
  • それぞれの長所と短所は何ですか？
  • 特定の状況で、一方が他方よりも優れているか?
4

6 に答える 6

11

長所/短所についての考えを次に示します。Microsoft Velocity Distributed Caching ソリューションも追加しました。

InProc の長所

  • 利用可能な最速のオプション（すべてメモリ/ RAMにあります）
  • セットアップが簡単です (.config ファイルに新しいものは何も必要ありません..これがデフォルトの動作だと思います)。
  • 私が信じているほとんどの人はこれを使用しています。

InProc の短所

  • Web サイト (アプリケーション プール) が停止すると、すべてのセッション情報が失われます。
  • WebFarm シナリオでは機能しません -> セッション情報はアプリ プールごとのみです。
  • 非セッション情報を含めることはできません。

StateServer の長所

  • メモリ/RAMでは高速なので（ただし、ネットレイテンシが多少あります..以下を読んでください）、Inprocほど高速ではない可能性があります。
  • Web ファーム シナリオの既定の構成。複数の iis サイトは、stateserver を使用して状態セッション情報を制御します。

StateServer の短所

  • ASP.NET StateServer サービスを実行するように設定する必要があります。
  • StateServer は、「リモート iis マシン」リクエストを受け入れるために、いくつかの設定調整が必要です。
  • iis リクエストが別のネットワーク化されたマシンでセッション情報を取得/設定する必要がある場合、わずかな正味の遅延が発生します。
  • 非セッション情報を含めることはできません。

Pro's for SqlServer (状態サーバーとして)

  • iis サイトが再起動した後でも、状態は常に保持されます。

SqlServer の短所 (状態サーバーとして)

  • 最も遅いソリューション -> 正味の遅延とハード ドライブの遅延 (SQL サーバーがハードディスクに状態を保存する/ハードディスクから読み取るため)。
  • セットアップ/構成が最も難しい。
  • 非セッション情報を含めることはできません

Velocity (またはその他の分散キャッシング システム) の長所

  • セッション情報だけでなく、オブジェクト、アプリケーション設定、キャッシュなどを処理できます (これは非常に良いことです!!)
  • メモリのみにすることも、データベースに永続化することもできます。
  • 1 つの「ノード」に障害が発生しても、システムは引き続き機能します。(2 つ以上のキャッシュ ノードがあると仮定)

Velocity (またはその他の分散キャッシング システム) の短所

  • 通常、費用は$$$
  • セットアップが最も難しい (インストール、構成の微調整、特別なコードの追加が必要)。
  • ネットワーク遅延があります (通常は何もありません) が、サービスがデータを保持している場合 (SQL Server など) にハード ディスク遅延が発生する可能性があります。
于 2009-04-19T08:12:31.057 に答える
3

ある種の Web ファームを使用していることが前提になると思います。

ステート サービスの 1 つの用途は、Web ガーデン (同じマシン上の複数のワーカー プロセス) です。この場合、負荷分散を使用してユーザーの接続を特定のサーバーに維持し、n 個のワーカー プロセスがすべて同じ状態サービスを共有するようにすることができます。

編集: Web ガーデン + 状態サービスまたは SQL サーバーのシナリオでは、接続されたクライアントがセッションを失うことなく、そのマシン上のワーカー プロセスをリサイクルできるという利点もあります。

私は SQL Server をセッション状態ストアとして使用することに慣れていませんが、クラスター内で SQL Server を使用することで堅牢性が向上すると思います。この場合、複数のワーカー プロセスと複数のサーバーを使用できますが、スティッキー セッション (サーバー アフィニティ) を使用する必要はありません。

もう 1 つ注意してください。状態サービスを 2 台目のマシンで使用し、ファーム内のすべてのサーバーをそのマシンにヒットさせることができますが、単一障害点が発生します。

そして最後に、サードパーティ (およびいくつかの自家製) 分散状態サービスのようなアプリケーションがあります。これらのいくつかは、他のオプションよりもパフォーマンス上の利点があり、さらに Session_End イベントが実際に発生します。(State Service と SQL Server セッション バッキングの両方で、Global.asax の Session_End は起動しません (SQL Server にフックする方法がある場合があります))。

于 2008-10-22T00:56:16.337 に答える
1

n 層環境では、SQL Server がセッション状態をホストしているため、バックエンドへの追加のネットワーク トラフィックが作成され、その追加のトラフィック (セッション関連の要求) を処理する必要がある SQL Server リソースが失われます。 ）。また、SQL Server の状態管理は、状態サーバーよりも低速です。

ただし、不測の事態でサーバーがダウンした場合、ステート サーバーではなく SQL Server がセッション情報を維持する可能性が高くなります。

于 2008-10-22T02:41:54.580 に答える
0

単一のマシンを使用して Web ガーデンに状態を保存することは、単一障害点を意味します。SQL 状態を使用しますが、多少のオーバーヘッドが追加されます。

于 2008-10-22T11:23:45.803 に答える
0

In Proc は非常に高速です。しかし、制限があります。単一のシステムのみを使用できます。システムを再起動すると、情報が失われます。同じマシン内のワーカー プロセス

StateServer はセッション情報を他のマシンに保存しました。Web ファームはセッションを使用できます。例：複数のワーカープロセスがサーバーからセッション情報にアクセスできます。サーバーを再起動すると、情報が失われます。

SQLServer は、テーブルに情報を格納するために使用されます。デフォルトでは、TempDB に保存されます。この tempdb は、sqlservice が呼び出された後に動的に呼び出されます。したがって、これもデータを保持しません。このシナリオでは、カスタム オプションと呼ばれるスクリプトを使用して独自の DB に格納できます。

于 2009-02-09T10:33:32.283 に答える
0

私の個人的な経験では、セッション変数に保存する際にいくつか問題がありました。私はセッションを失い続けましたが、それはウイルス対策だったと思います。サーバー内のすべてのファイルをスキャンしていたので、IIS はサイトを再コンパイルしてセッションを殺しました。(私はそのサーバーに対して何の力も持っていなかったと言わざるを得ません。私はそこでアプリをホストするように言われました)
そこでセッションを SQL Server に保存することにしました。今では誰もが満足しています...信じられないほど高速です

この記事を参考にして、簡単に始めましょう

于 2008-10-22T02:51:37.867 に答える