1

IISでホストされているWCFRESTサービスがあります。クライアント（主にブラウザ）は、時折ハングすることについて不平を言っています。私はついにこれを自分で体験し、サーバーからデバッグ情報を取得することができました。IIS管理コンソールから次のスクリーンショットを取得しました。

ハンギングリクエスト

明らかに、これらの要求はすべて非常に長い間存在していました。

これらのリクエストがハングしている間、サーバーは他のリクエストを問題なく処理できました。アプリプールを数回リサイクルしましたが、明らかな効果はありませんでした。この間、ブラウザからのリクエストはすべてハングし、ブラウザによってタイムアウトになります。同じマシン上の他のブラウザは、問題なく同じサービスに接続できました。また、Fiddlerを起動し、「ハングした」ブラウザーからFiddlerを介してリクエストを行うことができました。Fiddlerをシャットダウンすると、ブラウザが再び「ハング」しました。ようやくブラウザを完全に閉じたとき、接続が失われました。

潜在的に重要なポイントの1つ：スクリーンショットではわかりませんが、リクエストはすべて、バイナリストリーム（写真とビデオ）をクライアントに送信する呼び出しにかかっています。裏で、Azure Blob Storageからストリームを開き（OpenRead（）を使用）、関数から同じストリームを返します。つまり、一方の側でネットワークを介して読み取り、もう一方の側でデータをネットワークに送り出しているのです。

では、ここで何が起こっているのでしょうか。接続がハングするのを防ぐにはどうすればよいですか、または少なくとも適切な時点で接続がタイムアウトになるようにするにはどうすればよいですか？

更新：ブラウザに問題があるようです。ページにHTML5<video>要素があり、ビデオが十分に大きい場合、ブラウザーはファイルをダウンロードして永久に開いたままにするための接続を開いているように見えます。私はそれについて約75％しか確信していませんが、確実にわかった場合は、ここに更新を追加します。

4

3 に答える 3

0

次回これが発生したときは、同じブラウザの別のインスタンスを実行し、他のブラウザ（Firefox、Chrome、IEなど）も起動します。問題が特定のブラウザに関連しているかどうかを判断する必要があります。

ブラウザにバグを発見したと思います。Fiddlerの介入によって一時的に解決されるという事実は、特定のプロトコルスタックを介した接続の状態管理に関係していることを示唆しています。その場合、問題は特定のブラウザのインス​​タンスに限定されていることがわかります。

ブラウザベンダーに報告する以外に、それについてできることは何もありません。

バグがIEとAzureの間でのみ発生することを示すことができる場合、バグはAzureの癖によって引き起こされる可能性があります。その場合、単一ベンダーの問題であるため、解決策を得る可能性は「地獄の雪だるま」から向上します。 「息を止めないで」。

于 2012-05-04T04:06:50.270 に答える
0

Fidlerはプロキシであり、既存のプロキシの代わりにプロセスに自身を注入します。これにより、あなた（および他の人）が自動プロキシ設定またはその他のプロキシ設定に関連する問題を抱えていると私は信じています。

于 2012-05-04T04:50:17.380 に答える
0

問題は完全にブラウザにあることがわかりました。複数の<video>タグが含まれているページがいくつかあります。場合によっては、ブラウザが各ビデオの接続を開き、ビデオが再生されるまで開いたままにすることがあります。

少なくとも2つの異なるブラウザ側の回避策があります。

  1. タグに属性<video>を追加しpreload="none"ます。
  2. デフォルトでは動画を表示しません。<video>代わりに画像を表示し、ユーザーがクリックしたときにタグを動的にレンダリングします。

また、これに対応してくださった方々にもお詫び申し上げます。正解を見つけるのに十分な情報を提供しなかったので、本当にチャンスはありませんでした。

于 2012-05-08T19:01:10.227 に答える