web-dev-qa-db-ja.com

Azure Web AppのHttpキューの長さのメトリックは何ですか？

Azure Web AppのHttpキューの長さのメトリックは何ですか？

私のWebアプリは常に150を超えています。

App Serviceで有効にできるデフォルトのアラートのデフォルトのしきい値は100であるため、心配しています。

SignalRの使用はこのメトリックに影響しますか？

編集：

これが典型的な日負荷です： enter image description here

azuresignalrazure-web-sites
14
Guillaume Morin

[〜＃〜]編集[〜＃〜] 2016年11月12日

いくつかのフォローアップ情報に基づいて、HTTPキューの長さは、ある時点ですぐに期待と一致します。

修正後、サーバーファームのHTTPキューの長さのメトリックは、サーバーファーム（アプリサービスプラン）の実際のHttpQueueLength（現時点では現在のリクエスト値を誤って表示しています）を表すことを確認しました。この修正は、今後数週間ですべての地域に展開されます。

Azure Supportとの対話では、HTTPキューの長さは実際には紛らわしい名前であり、「W3SVC_W3WP」、「アクティブな要求」、「_ Total」にマップされます。

これが完全な応答です

こんにちはシェーン、あなたは正しいです、私たちはhttpキューメトリックの問題に気づきました、そこで私たちはこのメトリックがキューに入れられたのではなくアクティブなリクエストの合計を計算していたので、このメトリックに基づくWebアプリが誤解を招くことがわかりましたリクエストがあり、このメトリックについて製品チームと話し合いましたが、メトリックHTTPキューの名前には少しあいまいさがあります。実際には、ポータルに表示されるカウンターは、「W3SVC_W3WP」、「Active Requests」、「_ Total」に対応します。つまり、このカウンターはキューを表すのではなく、現在実行中の要求を表します。また、製品のソースコードを調べて、これを確認しました。カウンターの名前が混乱を招く可能性があることを理解しており、製品チームに名前を変更するようリクエストを送信しました。製品チームは、名前を変更すると顧客が持つ可能性のある既存のアラートが壊れる可能性があることを懸念していますが、同じ値を調べる「アクティブリクエスト」という名前の別のメトリックを追加し、後で「HTTPキューの長さ」を削除することを検討しています。これを念頭に置いて、Http Request Queueを使用する代わりに、他のメトリック（CPU /メモリなど）を使用して自動スケール/アラートルールを構成することをお勧めします。

数日前にプロダクトチームと話し合いましたが、現在、カウンター値が「リクエスト」用であり、実際のHttpキューの長さではないことを表すためにこれを更新する作業を行っています。

彼らもこれを言っていたので、この区別はすぐに無関係になりますが

こんにちはシェーン、私は自分の側でこれをテストしていましたが、ポータルがサイトレベルで更新され、このメトリックが「リクエスト」として表示されていることがわかりました。この変更がサーバーファームの設定にプッシュされるのをまだ待っていると思います。

アラートを選択した場合。 [リソース]ドロップダウンで[サイト]を選択してサイトを選択すると、メトリックに[リクエスト]が一覧表示されます。これが現在のリクエストになります。

したがって、現在の状態では、このメトリックは、システムが処理できないバックアップ要求があることを示していないことに注意してください。

9
Shane Neuville

Httpキューの長さ：保留中のHTTP操作の数。アプリケーションがWebサーバーが処理できるよりも多くの要求を受信して​​いる場合、これがギャップである可能性があります。つまり、リクエストのフォールアウトがあり、現在の構成では負荷をサポートするのに十分ではありません。 portal.Azure.comを使用します。HTTPキューの長さのデフォルトは1から始まります

enter image description here

SignalR for Socketsを使用していると思いますが、ソケットはWebサーバーとの接続を維持していますが、HTTPキューの長さは、Azureが処理できなくなったという理由だけで、Azureによってキューに入れられたWeb要求の数です。さらに分析しない限りわかりません。

7
Brij Raj Singh - MSFT

リクエストがHTTPキューで終了する場合は、リクエストを処理するために使用できるスレッドがないことを意味します。 Keremが示唆しているように、スレッドを待機状態にする（要求を処理できない）長いI/O呼び出しがある可能性があります。これは、CPUとメモリが少ないために発生する可能性が高くなります。

Enter/exitメソッドにDiagnostic.Traceを追加し、それらのメソッドに出入りするのにかかる時間をアプリケーションログで確認できます。

別の方法として、Visual Studioにリモートで接続し、スレッドの動作を確認します。何人待っていますか？

そして別のアプローチは、メモリダンプを取ることです（おそらくkuduサイトから）。次に、スレッドが実行していることを確認します。WinDbgの場合：！CLRStack -a * 〜KB

Visual Studioで.dmpファイルを開き、[管理されていない]を選択して、スレッドを確認することもできます。すべて/ほぼすべてのスレッドが待機中よりもWaitFor *** Objectにある場合、IO完了。この場合、インスタンス化を増やすと問題が解決/減少するのは事実ですが、そうなるでしょう。 IOに非同期バージョンを使用するようにメソッドを変更することをお勧めします。

hth、アルド

1
aljj