1

IISとAzureで非常に深刻な問題が発生しています。これがIIS側のものなのか、カスタムコード側のものなのかわからない。

Azureで実行されている2つのWebサイト（サイトAとサイトB）に関与しています。（標準のWebRoles、ASP.NET MVC3）。これらのサイトは両方とも完全に異なって設計されており、互いに関係はありませんが、どちらも同様の状況下で同様の動作を示しています。

サイトAは、セッション状態を有効にして実行されています。セッションはSQLAzureデータベースに保存されます。サイトAへの呼び出しのほとんどは、SQLAzureデータベースを指すASP.NETSQLメンバーシッププロバイダーを介して保護されています

サイトBは、セッション状態も有効にして実行されています。セッションはAzureAppFabricキャッシュに保存されます。サイトBには、AppFabricキャッシュおよびAzureテーブルストレージと通信するhttpハンドラーもあります。

問題は始まりますが、主要なAzureリソース（SQL Azureやキャッシュなど）が非常に遅くなった場合は回復しません。これらのリソースが非常に遅くなり、各要求の処理時間が1分を超えると、Azureのロードバランサーはそれらの接続を終了しますが、Webロール上のIISは、アクティブキューからこれらの要求をクリア/削除しません。

したがって、問題は、SQLAzureまたはAppFabricキャッシュが非常に遅い場合にサイトが応答しないということではありません。大きな問題は、SQLAzureまたはAppFabricCacheが戻ってきて正常に動作し始めたときに、サイトが回復しないことです。リクエストはアクティブリクエストリストにあり、長時間（数時間？）消えることはありません。率直に言って、私たちはそれらのサーバーをできるだけ早く再起動するので、それらがどれくらいの間そこに座っているのかわかりません。Azureリソースには断続的な問題が発生する可能性があり、両方のサイトへのトラフィックが非常に多いため、両方のサイトは、クリアされない要求の重みですぐに停止します。IISキューがいっぱいになり、誰かがアプリプールに入って再起動するまで、サイトは利用できません。

4

2 に答える 2

2

IIS が要求を「有効」に保つという事実は、非常に奇妙です。リクエストのタイムアウトを 60 秒未満に設定してみましたか? これを行うと、ロード バランサーが接続を閉じるのではなく、IIS が要求を強制終了するように制御されたままになります。

<httpRuntime executionTimeout="50" />

注: これは、Debug = false の場合にのみ機能します。

于 2012-07-25T18:39:35.790 に答える
0

同様の問題、非常に長い間続く IIS 要求がありました。なぜIISがそれらを殺さなかったのかを理解するのに長い時間を費やしました. Sandrino Di Mattia のソリューションなどを試しましたが、どれもうまくいきませんでした。

リクエストはまだアクティブであったため、IIS はリクエストを強制終了していないことが判明しました。場合によっては、クライアント ブラウザが接続を開き、それを永久に保持することがありました。ブラウザーのネットワーク デバッガー (Firebug、Webkit インスペクターなど) を調べると、そこに座っているだけで回転している要求が表示されます。私が知る限り、彼らはキープアライブに応答していたので、IIS とロード バランサーは接続と要求をアクティブに保ちます。究極の解決策は、ブラウザーがそれを行わないようにすることでした。

あなたの問題とは関係ないかもしれませんが、私の場合、問題は<video>タグでした。大きなファイルを指すタグが与えられると<video>、彼らはすぐに接続を開き、ビデオが再生されるまでそれを保持します。<video>解決策は、ビデオを再生する準備ができるまでタグを作成しないことでした。

また、Azure ロード バランサーが要求を強制終了したことを知る方法はありますか? アクティブなリクエストを確認する唯一の方法は、IIS 管理コンソールを使用することです。

于 2012-07-26T18:45:24.200 に答える