ASP.Net Webアプリケーションのすべてのリクエストがリクエストの最初にセッションロックを取得し、リクエストの最後にそれを解放することを発見しました！ 最初に私がそうであったように、これの影響があなたに失われた場合、これは基本的に以下を意味します： ASP.Net Webページの読み込みに時間がかかる（データベースの呼び出しが遅いなどの理由で）場合があり、ユーザーは待機に飽き飽きしているため、別のページに移動することを決定します。ASP.Netセッションロックにより、新しいページ要求は、元の要求が非常に遅いロードを終了するまで強制的に待機します。ああ。 UpdatePanelの読み込みが遅く、ユーザーがUpdatePanelの更新が完了する前に別のページに移動することにした場合...できません。ASP.netセッションロックにより、新しいページ要求は、元の要求が非常に遅いロードを完了するまで強制的に待機します。ダブルアレ！ それで、オプションは何ですか？これまでのところ私は思いつきました： ASP.NetがサポートするカスタムSessionStateDataStoreを実装します。私はコピーするほど多くを見つけていません、そしてそれは一種のリスクが高く、簡単に失敗するようです。 進行中のすべてのリクエストを追跡し、同じユーザーからリクエストが届いた場合は、元のリクエストをキャンセルします。ちょっと極端に思えますが、うまくいくと思います。 セッションを使用しないでください！ユーザーに何らかの種類の状態が必要な場合は、代わりにキャッシュを使用し、認証されたユーザー名のキーアイテムなどを使用できます。再び極端なようです。 ASP.Net Microsoftチームがバージョン4.0のフレームワークにこのような巨大なパフォーマンスのボトルネックを残したとは本当に信じられません！明らかなものがないのですか？セッションにThreadSafeコレクションを使用するのはどれほど難しいでしょうか。