ASP.Net Web アプリケーションのすべてのリクエストは、リクエストの開始時にセッション ロックを取得し、リクエストの終了時にセッション ロックを解放することを発見しました。
この意味があなたには分からないかもしれないが、私も最初はそうだった。つまり、これは基本的に次のことを意味する。
ASP.Net ウェブページの読み込みに長い時間がかかっている場合 (データベース呼び出しが遅いなどの理由による)、ユーザーは待ち疲れて別のページに移動しようとしても、移動できません。ASP.Netセッション ロックにより、新しいページ要求は元の要求の非常に遅い読み込みが完了するまで待機させられます。ああ。
の読み込みが遅い場合、更新が完了する
UpdatePanel前にユーザーが別のページに移動しようとしても、できません。ASP.Netセッション ロックにより、新しいページ要求は、元の要求の非常に遅い読み込みが完了するまで待機させられます。二重の Arrrgh!UpdatePanel
では、どのような選択肢があるのでしょうか? これまでのところ、次のような選択肢が考えられました。
- ASP.Net がサポートするカスタムを実装します
SessionStateDataStore。コピーできるものがあまり見つからず、リスクが高く、間違いやすいようです。 - 進行中のすべてのリクエストを追跡し、同じユーザーからリクエストが届いた場合は、元のリクエストをキャンセルします。少し極端に思えますが、うまくいくと思います。
- Session は使用しないでください。ユーザーの何らかの状態が必要な場合は、
Cache代わりに、認証されたユーザー名のキー項目などを使用できます。これもまた、極端に思えます。
ASP.Net Microsoft チームがバージョン 4.0 のフレームワークにこのような大きなパフォーマンスのボトルネックを残していたとは、本当に信じられません。何か明らかなことを見逃しているのでしょうか?ThreadSafeセッションにコレクションを使用するのはどれほど難しいのでしょうか?
ベストアンサー1
ページでセッション変数を変更しない場合は、このロックのほとんどをオプトアウトできます。
<% @Page EnableSessionState="ReadOnly" %>
ページでセッション変数が読み取られない場合は、そのページに対してこのロックを完全に無効にすることができます。
<% @Page EnableSessionState="False" %>
どのページもセッション変数を使用していない場合は、web.config でセッション状態をオフにするだけです。
<sessionState mode="Off" />
興味深いのですが、ロックを使用しない場合、「ThreadSafe コレクション」はスレッドセーフになるために何をすると思いますか?
編集: 「このロックのほとんどをオプトアウトする」とはどういう意味か、説明する必要があるかもしれません。読み取り専用セッションまたはセッションなしのページは、相互にブロックすることなく、任意の数の特定のセッションで同時に処理できます。ただし、読み取り/書き込みセッション ページは、すべての読み取り専用要求が完了するまで処理を開始できず、実行中は一貫性を維持するためにそのユーザーのセッションに排他的にアクセスする必要があります。個々の値をロックしても機能しません。1 つのページが関連する値のセットをグループとして変更するとどうなるでしょうか。同時に実行されている他のページがユーザーのセッション変数の一貫したビューを取得するようにするにはどうすればよいでしょうか。
可能であれば、一度設定されたセッション変数の変更を最小限に抑えることをお勧めします。これにより、ページの大部分を読み取り専用セッション ページにすることができ、同じユーザーからの複数の同時リクエストが互いにブロックされなくなる可能性が高まります。