[解決済み】すべてのASP.Netのウェブサイトが遅い理由を発見しました。

質問

ASP.NetのWebアプリケーションのすべてのリクエストは、リクエストの開始時にセッションロックを取得し、リクエストの終了時にそれを解放することを発見しました。

私が最初にそうだったように、このことの意味がわからないかもしれませんが、これは基本的に次のことを意味します。

• ASP.Netのウェブページの読み込みに時間がかかっているとき（データベース呼び出しが遅いとか）、ユーザーが待ちくたびれたから別のページに移動したいと思ったとき、それができないのです！ ASP.Netのウェブページの読み込みに時間がかかっているとき、ユーザーが別のページに移動したいと思ったとき、それができないのです！ ASP.Netのウェブページの読み込みに時間がかかっているとき、ユーザーが次のページに移動したいと思ったとき、それができないのです。ASP.Netのセッションロックにより、新しいページのリクエストは、元のリクエストがひどく遅い読み込みを終えるまで待たされるのです。あーあ。

• UpdatePanelの読み込みが遅く、UpdatePanelの更新が完了する前にユーザーが別のページに移動することを決定した場合、いつでも... それはできません! ASP.netのセッションロックにより、新しいページへのリクエストは、元のリクエストがひどく遅いロードを終えるまで待たされるのです。二度手間だ!

では、どのような選択肢があるのでしょうか。 今のところ、私が思いついたのは

• ASP.NetがサポートするCustom SessionStateDataStoreを実装する。 あまり真似できるものがなく、リスクも高く失敗しやすいような気がします。
• 進行中のすべてのリクエストを記録し、同じユーザーからリクエストが来た場合は、元のリクエストをキャンセルする。 ちょっと極端な気もしますが、うまくいくでしょう（と私は思います）。
• セッションは使わないでください ユーザーの状態が必要なときは、代わりにCacheを使って、認証されたユーザー名などをキーアイテムにすることができます。これも極端な話ですが。

ASP.Net Microsoft チームが、バージョン 4.0 のフレームワークにこれほど大きなパフォーマンスのボトルネックを残したとは、本当に信じられません! 私は何か明らかなことを見逃しているのでしょうか？セッションにThreadSafeコレクションを使用することは、どれほど難しいことなのでしょうか？

どのように解決するのか？

さて、Joel Mullerの意見に大感謝です。私の最終的な解決策は、このMSDN記事の最後に詳述されているCustom SessionStateModuleを使用することでした。

http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstateutility.aspx

これでした。

• 非常に短時間で実装できる（実際、プロバイダ経由よりも簡単だと思われる）。
• ASP.Netの標準的なセッション処理の多くをそのまま使用した（SessionStateUtilityクラスを介して）。

これによって、アプリケーションに大きな違いが生まれました。 ASP.Net Sessionのカスタム実装が、リクエスト全体に対してセッションをロックしていることが、いまだに信じられません。 これは、Webサイトに膨大な量の遅さを追加するものです。 私が行ったオンライン調査の量から判断すると（そして、本当に経験豊富なASP.Net開発者数名との会話）、多くの人がこの問題を経験していますが、その原因を突き止めた人はごくわずかです。 スコット・グーに手紙を書こうかな...。

これが何人かの人の助けになれば幸いです