Shardingしてみても同じマシンだとあまり変化でなかったです。いうのもCPUを最も使ってるのがIISExpressのプロセスだったので、アプリケーションが遅いってことですから。あとは、マシン分けて計測しかないですが、少なくとも同一環境内ではMongoDBでのSessionStateStoreがStateServerに負けないくらいの速度を実現しました(何度か試したらStateServerはもっと早かったけどー、そこは情報操作!)。Dictionary<string,object>の実装で最速。アプリけーションのリサイクルと同時にセッションが破棄されるのと複数プロセス間で共有できないです。StateServer(専用プロセスによるインメモリステート管理)InProcの弱点である、アプリけーションのリサイクルによる破棄とプロセス間共有を実現出来るようにしたもの。プロセスをまたぐのでシリアライズコスト発生するけど、インメモリなのでInProcにつぐ速度を実現。シングルプロセスでの実装になるので、耐障害性という意味では弱い。ステートをホストしているマシンの障害や再起動などでセッションが破棄されてしまいます。SQLServer(ストーレジに保持するステート管理)StateServerの弱点であり、耐障害性をクリアしたストレージ保存型でのセッション管理。シリアライズコスト+DBサーバーのパフォーマンス次第で遅くもなるし早くもなる。Custom(SessionStateStoreProviderBaseを派生したカスタム実装)キャッシュクラスタ(Velocity)を利用したり、EntityFrameworkを利用した実装(UniversalProvider)を使ったりSessionStateStoreに対してイロイロです。DBをSQLServer以外にする場合にも利用されてます。選択肢多くていいですね。標準のものもそれぞれ優秀で素晴らしいです。SessionIDの生成や、クライアントとのやり取りは別の仕組みで実装されてるので、SessionStateStoreProviderのカスタムとは分離されてて安心です。AdaTheDev最近、すっかりMongoDBに心奪われてる身としては、SessionをMongoDBに入れてしまいたいという衝動にかられてます。あれやこれやの問題もあり、SQLServerだけにたよるソリューションだとよろしくないなというのもありまして。MongoDB、大変優秀ですね。ReplicaSet(レプリケーション)による可用性の確保(自動フェールオーバー有り)と、Sharding(データのパーティショニング)によるパフォーマンスの確保、素晴らしいです。試して部分的に利用を始めてる段階で、まだまだ自信をもって使いまくるって言う状況ではないですが、ちょっとずつです。使っていってSQLServer+MongoDBで行けるところまで行ってみようと企んでます。TraceListnerのMongoDB化。前回のエントリでそれっぽい感じのものを提示しましたが、これでサーバー群のトレース情報を低コストなストレージに保持出来るようになりますね。トレース情報くらいなら万が一情報欠落しても致命的になることも無いでしょう。!セッションはそういうわけにはいきませんね。システムとして提供している表の機能に影響がでちゃいますからね。なると、ReplicaSetの機能を利用することは必須となりましょう。するとFailoverの時の挙動を確認したりする必要も出てきますよね。いうテストを繰り返してこそですよね。ReplicaSetでMongoDBを2つ起動。ArbitarっていうSQLServerでいうところのウィットネスサーバーを1台追加してないと投票結果が偶数とかになって次のPrimary決定時に困っちゃうことがあるので、3ノード起動します(詳しくはオフィシャルサイトでどーぞ)。c:\mongo\dbr2これで起動してるので(c:\mongoに一式ある前提です)、まずは初期化。localhost:27031初期化コマンド順番に実行すればOKです。rs.initiate()rs.add("hostname:27031")rs.add("hostname:27032")rs.addArb("hostname:27020")まずはこの状態で公開されてるソースを利用してSessionを使ってMongoDBにデータを入れてみましょう。MVC4DPでアプリケーションを作り、Home/IndexアクションでSessionに値をいれて、Home/Indexビューで表示するだけのものです。GitHub↑ここからソースを取得して、プロジェクトに追加。Driverを入れておきましょう。コメントに従い、接続文字列を指定するとレプリカセットにならないので、今回起動したMongoDBを指すように接続文字列を変更。connectionString="mongodb://localhost:27031,localhost:27032/"ちゃんと出来てますね。MongoVUEで27031(primary)データを確認。続いて27032(Secondary)のデータを確認。強制フェールオーバーを実行。この状態で再度先ほどの起動したブラウザでF5でリロード。動くなら、これでFailoverしたほうを参照して、表示されるはず!タターン!うまくいきました。内部ではSafeModeっていう書き込み確認モードで動作するようになってるので、手堅いです。27032(SecondaryからPrimaryに変更したノード)でSessionsコレクション(テーブルですね)を確認して見つつブラウザのF5リロードを繰り返すと、ちゃんとLockIdがカウントアップしていくので、読み込みも書き込みもFailover後にちゃんとできてるのが確認できます。Benchでリクエストを投げまくってみると、最後まで完了せずにエラーで途中終了してしまいます。システムのバッファー領域が不足しているか、またはキューがいっぱいなため、ソケット操作を実行できませんでした。男気あふれる強気のエラーメッセージ。Driver!長くなったのでつづく...。