IISのハングを引き起こしたASP.NETセッションを再度有効にする

Question

私は、最も重要なサイトの2つ（IIS7ではASP.NET）を実行しているクライアントのWebサーバーでいくつかのフェールセーフを実装しようとしています。私は、アプリケーションプール制限を設定して、w3wpプロセスが90％+ CPUを1分以上使用すると、それが強制終了され（任意の訪問者に一時的に503のService Unavailableメッセージを生成します）、ローカルテストの意志に基づいて1分以内に再起動することができます。これは、1つのCPUを使用してサーバーを長時間停止させるよりも優れたソリューションです。

ローカルのIIS7インスタンスでの私の試合中に、リクエストが "Kill.aspx"を呼び出すと、サイトが復帰してもIISがそれを引き起こしたセッションを提供しないことに気づいたぶら下がる私は別のセッションからテストサイトを再起動することしかできませんが、 "キラー"ブラウザでクッキーをクリアすると、すぐにサイトにアクセスできます。

したがって、IISがこれを抑制しようとしている悪意のある行為は、わずかに決定された対戦相手に対しても機能しません。ほとんどの場合、排泄物がファンに当たった場合、それはコーディング/構成エラーであり、その時にページを要求したユーザーの過ちではありません。

したがって、私はこの機能をオフにしたいと思っています。なぜなら理論上のユーザーは、サイトに再度アクセスする前にクッキーをクリアする必要がないからです。どのようにこれが可能であるかについて私は本当に感謝しています。

Answer 1

Yousは、In-Procの代わりにASP.Net Session StateServerを使用する必要があります（詳細はmsdnを参照）。そうすれば、セッションは異なるプロセスで実行され、IISクラッシュの影響を受けません。

Answer 2

"機能"をオフにしますか？ワーカープロセスがリセットされた場合（そしてあなたがin-procセッションを使用している場合）、セッションはリセット時に吹き飛ばされます。

セッションストレージを状態サーバーまたは他の処理不能シナリオに移動することを検討したい場合があります。

また、1つのプロセスが強制終了され、他のプロセスがコンテンツの提供を続ける場合、この方法で複数のワーカープロセス（別名：Webガーデン）を使用するようにアプリケーションプールを設定できます。

次に、別のオプションとして、複数のWebサーバーを設定し、それらの負荷を分散することができます。

最後に、アプリケーションをプロファイリングして、どのようにしてアプリが無限に回転しているかを正確に把握したい場合があります。私の推測では、あなたは単にこのアイデアを隠蔽している多くのコード問題があるということです。