Wie lautet die Http-Warteschlangenlänge in Azure Web App?

BEARBEITEN 11/12/2016

Aufgrund einiger weiterer Informationen wird die HTTP Queue Length hier bald mit den Erwartungen übereinstimmen.

  

Ich habe die Bestätigung erhalten, dass nach dem Fix, der   Die Metrik "HTTP Queue Length" für die Serverfarm zeigt die tatsächlichen Werte an   HttpQueueLength (es zeigt fälschlicherweise den aktuellen Requests-Wert an   zu diesem Zeitpunkt) für die Serverfarm (App Service Plan). Dieses Update wird   in den kommenden Wochen in allen Regionen ausgerollt werden.

Beim Sprechen mit der Azure-Unterstützung ist die Länge der HTTP-Warteschlange in Wirklichkeit ein verwirrender Name und entspricht "W3SVC_W3WP", "Aktive Anfragen", "_Total".

Hier ist die vollständige Antwort

  

Hallo Shane, Sie haben Recht, wir hatten ein Problem mit der http-Warteschlangenmetrik festgestellt, wo wir das in Auto-Scaling / Alert einer Web-App herausgefunden haben   basierend auf dieser Metrik war irreführend, da diese Metrik die   insgesamt aktive Anfragen und nicht die Anfragen in der Warteschlange und wir hatten eine   Diskussion mit unserem Produktteam über diese Metrik und es erscheint   dass es im Namen der Metrik HTTP ein bisschen mehrdeutig ist   Warteschlange. In Wirklichkeit entspricht der Zähler, den wir auf dem Portal zeigen, dem   zu "W3SVC_W3WP", "Aktive Anfragen", "_Total". Mit anderen Worten, das   counter stellt keine Warteschlange dar, sondern fordert sie an   zu jeder Zeit laufen. Wir haben dies auch durch Überprüfung überprüft   in unseren Produktquellcode. Wir verstehen, wie der Name des   Counter könnte zu Verwirrung führen und wir haben eine Anfrage an unsere gestellt   Produktteam, um es umzubenennen. Das Produktteam ist besorgt, dass das Umbenennen   könnte vorhandene Warnungen, die Kunden möglicherweise haben, aber sie sind   in Betracht ziehen, eine weitere Metrik namens "Active Requests" hinzuzufügen, die aussieht   bei gleichem Wert und später "HTTP Queue Length" entfernen. Halten   In diesem Sinne war unser Vorschlag, eine andere Metrik (z   Beispiel: CPU / Memory), um Auto-Scale / Alert-Regeln statt zu konfigurieren   Verwenden der HTTP-Anforderungswarteschlange.

     

Ich hatte ein paar Tage zuvor mit unserem Produktteam eine Diskussion   und wir arbeiten gerade daran, diese aktualisiert zu haben, um darzustellen   dass der Zählerwert für "Anfragen" und nicht die wahre Http-Warteschlange ist   Länge.

Obwohl diese Unterscheidung bald irrelevant sein wird, da sie auch dies zu sagen hatten

  

Hi Shane, ich habe das gerade an meinem Ende getestet und ich sehe das   Portal wurde auf Site-Ebene aktualisiert, um diesen Messwert als anzuzeigen   "Anfragen". Ich denke, wir warten immer noch auf diese Veränderung   in die Einstellungen der Serverfarm verschoben.

     

Wenn ich Alert wähle. Wählen Sie im Dropdown-Menü "Ressource" die Option "Websites" aus   Wählen Sie Ihre Website, dann werden die Metriken "Anfragen" auflisten   seien Sie die aktuellen Anfragen.

Es ist also nur etwas zu beachten, dass diese Metrik in ihrem aktuellen Zustand nicht anzeigt, dass Sie Anforderungen haben, die das System nicht verarbeiten können.

Http Queue Length: Anzahl der ausstehenden HTTP-Operationen. Wenn Ihre Anwendung mehr Anfragen erhält als der Webserver verarbeiten kann, könnte dies Ihre Lücke sein. Das bedeutet, dass sich die Anforderungen verschlechtern und Ihre aktuelle Konfiguration nicht ausreicht, um die Last zu unterstützen. Verwenden Sie portal.azure.com. Der Standardwert für HTTP-Warteschlangenlänge beginnt bei 1

Ich denke, dass Sie SignalR für Sockets verwenden, während Sockets die Verbindung mit Ihrem Webserver aufrechterhalten. HTTP Queue Length ist die Anzahl der Webanforderungen, die vom Azure in die Warteschlange gestellt wurden, nur weil sie nicht mehr verarbeitet werden konnten Seien Sie, aber nicht sicher, wenn wir nicht weiter analysieren.

Wenn Anforderungen in die HTTP-Warteschlange enden, bedeutet dies, dass kein Thread zur Verarbeitung der Anforderungen verfügbar ist. Wie Kerem nahelegt, könnte es sein, dass es einige lange I / O-Aufrufe gibt, die die Threads in den Wartezustand versetzen (keine Anfragen zu bedienen). Dies ist sehr wahrscheinlich, da CPU und Speicher niedrig sind.

Sie können Diagnostic.Trace bei enter / exist-Methoden hinzufügen und im Anwendungsprotokoll nachsehen, wie lange es dauert, um von diesen Methoden aus zu arbeiten

Sie können Visual Studio auch remotlich anhängen und sehen, welche Threads ausgeführt werden. Wie viele warten?

Und ein anderer Ansatz wäre, einen Speicherabzug zu machen (vielleicht von der Kudu-Seite). Dann überprüfe was Threads machen: In WinDbg: ! CLRStack -a * ~ KB

Sie können die .dmp-Datei auch in Visual Studio öffnen, unmanaged auswählen und die threds überprüfen. Wenn sich alle / fast alle Threads in einem WaitFor *** -Objekt befinden, warten sie auf eine IO-Completion. In diesem Fall ist es wahr, dass eine zunehmende Instanziierung das Problem lösen / verringern wird, aber es wäre besser, die Methoden zu ändern, um die Async-Version für IO zu verwenden.

hth, Aldo