InProc、StateServer、およびSQLServer for ASP.NETの状態管理を比較する多くの優れた情報を見つけましたが、パフォーマンスベンチマークの比較を見つけることができないようです。InProcがStateServerよりも高速であり、StateServerがSQLServerよりも高速であることは明らかですが、どれだけ高速であるかは明らかではありません。アプリケーションや環境によって大きく異なることは承知していますが、それらをどのように比較するかについて相対的な考え方を持っていることは価値があります。
実行されたベンチマークのうち、共有できるものを知っていますか？またはこれについて個人的な経験がありますか？ありがとうございました！
私には個人的な経験がありますが、共有するベンチマークや実際に記録された指標はありません. 最初に、InProc メソッドを使用して、通常よりも大きなユーザー オブジェクトをセッションに格納する Asp.Net サイトを作成しました。オブジェクトのサイズとエラー処理ライブラリの性質により、2 つの望ましくない動作が発生することがわかりました。1 つ目は、プロセス中にランダムな間隔でアプリケーション プールをリサイクルすることでした。w3wp.exe プロセスは途中で自身をリサイクルするため、本質的にセッションがダンプされ、オブジェクトが失われます。これにより、他のコードが起動してセッションを修復し、トランザクションのレイテンシが増加しました。また、セッション内のオブジェクトのサイズと、ページ自体のライブラリにロードされているいくつかのオブジェクトのサイズによって、 w3wp.exe がページインとページアウトを繰り返します。セッション オブジェクトまたはこれらのライブラリ オブジェクトのいずれかのみが関与し、両方は関与しない小さな要求の場合、プロセスで奇妙なページング動作は発生しませんでした。
InProc から StateServer に移行することで、リサイクルがすぐに得られることがわかりました。プールは実際にはリサイクルが少なくなり、セッションオブジェクトは別のメモリにとどまりました。また、これにより、ページングに関して上記で説明したように、普遍的な「ライブラリのみ」の状態が発生し、再び発生することはありませんでした (確かに、1 か月の稼働時間後にチェックを停止しました)。当時、特定のフレームワーク ライブラリへのアクセスで非常にわずかな遅延が発生していましたが、2.0 から 3.5 にアップグレードすると、これらのアクセスの異常は完全になくなりました。近いうちに 3.5 から 4.0 にアップグレードするときに、同様の動作を期待しています。
ステート コントローラーとして SQLServer を使用するテスト サイトが試みられましたが、最初のセッションの作成/保存で唯一のレイテンシーが見つかりました。SQL でセッションを更新/アクセスするための後続の呼び出しは、StateServer オプションと実際の違いはありませんでした。メトリックはありませんが、動作の違いを示すシステムはありませんでした。タイムスタンプには、すべての面で同等の違いがありました。使用できる可能性はほとんどありませんでしたが、得られた利点は、ユーザー データベースをセッション状態サーバーと直接結合し、タイムスタンプ、ステータス、およびその他の特殊なセッション変数を直接比較できることでした。この機能は実際には必要ありませんでした。また、StateServer オプションは既に運用サーバーで本格的に使用されていたため、そのままにしておくことにしました。
最終的に、StateServer の InProc をダンプするように私たちを説得したのは、速度ではなくメモリ使用量でした。アクセス速度の利点は、そもそもデータをメモリに保持する必要性を上回るものではありませんでした。
DevOps Guys の優れたベンチマークがあります。 http://www.slideshare.net/devopsguys/best-performing-aspnet-session-state-providersの比較
AppHarbor も memcached を推奨していますが、ベンチマークはありません。 http://support.appharbor.com/kb/tips-and-tricks/using-memcached-backed-sessionprovider を提供し、セッション プロバイダーを提供しますhttps://github.com/friism/Memcached-Providers