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!長くなったのでつづく...。MongoDBたまには週間たけはらブログ。ASP.NETでTraceListener使ってますか?今まで結構仕込んでおいたんだけど、ファイルやイベントログだと扱いにくいなー、なんて思ってませんか。融通効かないなー、と。大規模サイトなんかでSQLServerに入れちゃうと、大変なことにナチャウヨ。そこでMongoDB。みんな大好きMongoDB。ドキュメントの日本語化も着実に進んでるので、英語なんてー、と気にすることもあんまりないでしょう。ないですか?いろいろ可愛いやつですよ!ログデータの保持なんて、もう、得意中の得意です。保持する構造さえちゃんとしておけば、RDBじゃ処理しにくいものもお気楽に扱えます。用途と使い方次第デスけどね。ConfluenceMongoDBって何よ?っていうのは、いろいろ検索してね。部)開発環境で超簡単な使い方はコンソールでmongodを起動しておいて、mongoで中身を確認。mongodをサービス起動しておきたくなりますが、最初は単なるプロセス起動。内容確認をコンソールのmongoで行うのも、ハッカーみたいな雰囲気あっていいかもしれないけど、そんなの面倒なので実際はGUIのツールを使いましょう。MongoDB他にもイロイロあるので、気に入ったのを選んで試してみましょう。MongoDBこのMongoDBにTraceListenerからmessageを保存するようにしちゃいましょー!開発するならHTTPでのREST操作(MongoDBに最初からあります)よりも、Driverを使った開発のほうが楽チンぽんです。前までは、いろいろ使い勝手の問題もあったりとかしたけど、いまとなっては標準公開されてるもので十分です。MongoDB英語かよ!どんまい。ConfluenceなんにせよNuGetで取得できるのが便利なところです。galleryTraceListenerって自分で用意したことなかったんだけど、TraceListenerクラス派生でいいってことなので、お手軽ですね。必須なoverrideも2個だけ。...}やれそうですね。enabled="true"/>あとはSystem.Diagnostics.Trace.Write/WriteLineです!すでにたくさん仕込んでいる場合にはコレでOK。MVC3標準プロジェクトを作成して、MongoDbTraceListenerクラスを作成し、HomeControllerのIndexアクションにTraceを書いてみましょう。わーお!素敵!!MongoDBが違うマシンだったり(本番はそうしましょう)、Database名を変更したいときはappSettingsの値を変えてね。コレクション(テーブル相当)の名前を変えたかったらtrace/listnersのinitializeDataで指定してね。ちなみに、これだけだとつまんないので、ここから少し拡張してパフォーマンス計測してみましょう。IHttpModuleを実装して、リクエストの処理時間を計測するようにしてみます。Hosting↑パフォーマンス計測ならこんな素敵なもの(NuGit.orgで実物見れますよ~)もありますが...。これから新規ならこっちのほうが...。}}これを利用するためにsystem.webServer/modulesに登録します。</system.webServer>実行してみます。BeginRequestからEndRequestの間を計測するものですが490msって...。遅すぎ!と、思ったらF5リロードの2回目は5ms。ん?よく見たらStatusとMillisecondsがstringになってるー。TraceListenerのInternalWriteObjectでToStringしてたね。そこは修正しましょう。Insert(document);}これでちゃんと型どおり。BsonValueにはいろいろあるのでドキュメント参照してみてください。このHttpModuleがあればすべてのリクエストの処理時間が計測できますね!アクセスログのTimeTakenとダダカブリ。フィールドは何を表し、何を意味していますか。MVCならActionFilter属性を使ってControllerでの処理時間とViewの処理時間をそれぞれ別で計測できてなお嬉しいはず。Filterに追加しておきましょう。あとは実行するだけ!ズームして見てね。Controllerでの実行時間が223ms、ActionResultの実行時間が180ms、HttpModuleでの計測時間が497ms。差が94msありますね。ちなみにコレが初回実行時の計測で、2回目は↓。Controllerでの実行時間が0ms、ActionResultの実行時間が0ms、HttpModuleでの計測時間が10ms。これまた、そんなもんでしょう。こんな感じです!楽しいですね!途中、MongoDBに入れるDocumentのカラムを変更したりしてるけど、MongoDB側へは何も手を加える必要がないんです。ドキュメント単位(テーブルなら行単位)にカラム構成が変更されてもお構いなしです。ちなみにサーバーさえいればDatabaseもCollectionも初回アクセス時に勝手に作られるので準備は不要。この手軽さと、レスポンス性能の高さがMongoDBの魅力です。今回のプロジェクト一式は↓こちら。ローカルにMongoDBさえ入っていればそのまま動くはず。※ファイルを小さくするために、packages/mongocsharpdriver.1.2を消してます。