Anforderungen im IIS-Status "SendResponse" blieben lange Zeit hängen. Langsame IIS 7.5 / ASP.NET 4.0-Webanwendung

Ich habe eine Reihe von sehr bulligen, sehr wenig ausgelasteten Servern, auf denen einige virtuelle Maschinen mit Windows Server 2008 R2 und IIS 7.5 ausgeführt werden.

Das Problem: Manchmal dauert die Bearbeitung von Anfragen sehr lange. Der Benutzer sieht, wie sich sein Browser dreht, und erhält anscheinend keine Antwort von IIS.

Einige Statistiken und Lösungsversuche:

• Die Belastung der Server (Host und VM) ist vernachlässigbar. Die CPU geht nie über 5% hinaus, es stehen mehr als 10 GB RAM zur Verfügung, alles ist über MPIO mit einem schnellen SAN verbunden.
• Ich erhalte zwischen 30 und 50 Anfragen pro Sekunde, eine Mischung aus dynamischem und statischem Inhalt, nur GET und POST. Die meisten Treffer werden zwischengespeichert (80% Trefferquote), sodass die Belastung des Fabric / SAN / IO nahezu gleich Null ist.
• Das TCP-Offloading ist auf dem Host und der virtuellen Maschine sowohl auf dem Netzwerkadapter als auch durch Deaktivieren des TCP-Schornsteins deaktiviert
• Die Webanwendungen werden im integrierten ASP.NET 4.0-Modus ausgeführt. Sie tätigen keine langfristigen Anrufe bei Webdiensten von Drittanbietern oder dergleichen.
• Ich habe sowohl das processModel autoConfig ausprobiert als auch maxWorkerThreads, maxConnections, maxIOThreads usw. ohne Unterschied auf sehr hohe Zahlen gesetzt.
• Datenbankabfragen werden alle in weniger als 1 Sekunde abgeschlossen. Ich habe einen ganzen Tag lang ein Profil erstellt und keine einzige Abfrage erfasst, die länger dauern würde.
• Ich habe mir Tonnen von Leistungsüberwachungszählern angesehen. Die ASP.NET-Warteschlangen und Anwendungswarteschlangen sind immer leer, es scheint nichts in die Warteschlange zu geraten (was ohnehin keinen Sinn ergibt, wenn man bedenkt, dass der Server überhaupt nicht ins Schwitzen kommt).
• Ich habe mithilfe von Appcmd-Listenanforderungen festgestellt, dass Anforderungen in der IIS-Phase "SendResponse" manchmal 20 bis 60 Sekunden lang "hängen bleiben". Dies ist das einzige, was ich bisher finden konnte, das einen Sinn ergibt, warum Benutzer beim Navigieren stecken bleiben. Beachten Sie, dass die meisten Anforderungen schnell verarbeitet werden. Es sieht so aus, als würden zufällige Anforderungen aus verschiedenen Anwendungspools hier hängen bleiben.

Irgendeine Idee, was ich sonst noch sehen kann? Was würde dazu führen, dass Anforderungen in der Phase "SendResponse" in IIS hängen bleiben?

Haben Sie eine Lösung dafür gefunden? Ich sehe das schon seit einiger Zeit regelmäßig, wenn statische Inhalte wie JS, PNG und GIFs im Status "SendResponse" im Modul "IIS Web Core" stecken bleiben. Ich bin in der gleichen Situation mit IIS 7 / ASP.NET 4.0. Ich überwache diese mit diesem Microsoft.Web.Administration-Code und nicht mit appcmd.

UPDATE: Bei einigen weiteren Untersuchungen habe ich mir die Möglichkeit ausgedacht, dass es sich möglicherweise um eine unterbrochene Netzwerkverbindung handelt. In diesem ThreadDie Person meldet Win32-Statuscodes von 1236 in ihren IIS-Protokollen: "Die Netzwerkverbindung wurde vom lokalen System abgebrochen." Ich bin mir jedoch nicht sicher, ob dies bedeutet, dass der Anforderer die Anforderung abgebrochen hat oder der Webserver die Anforderung abgebrochen hat. Möglicherweise navigiert der Anforderer zu einer anderen Seite Ihrer Site, bevor alle diese HTTP-Anforderungen für Seiteninhalte (Bilder, JS usw.) abgeschlossen sind, wodurch wahrscheinlich alle ausstehenden Anforderungen an den Webserver abgebrochen werden (dh er klickt auf einen Link auf der Seite wenn es zum ersten Mal rendert). Ich habe einige 1236 Win32-Statuscodes in meinen IIS-Protokollen gefunden (hauptsächlich für statische Inhalte wie GIF, PNG und JS, von denen einige mit ASPX-Seiten verknüpft sind). Ich bin mir jedoch nicht sicher, ob dies dieselben Anforderungen sind wie ich Ich sehe im Status "SendResponse" stecken.

Dies ist normalerweise darauf zurückzuführen, dass mobile Geräte bei langsamen Datenverbindungen große Asset-Dateien herunterladen. Wenn ich "groß" sage, meine ich relativ zur Geschwindigkeit der Verbindung.

Die Anforderungen hängen nicht, sie dauern nur lange, da sie von der Netzwerkgeschwindigkeit des Benutzers abhängen. Die Anforderungen werden ausgegeben, wenn der Benutzer die Verbindung trennt, sodass er wahrscheinlich geduldig auf das Laden der Seite wartet.

Überprüfen Sie die IP-Adressen, die neben den "hängenden" Anfragen aufgeführt sind, und suchen Sie sie nach. Sie werden wahrscheinlich feststellen, dass sie Mobilfunkbetreibern gehören.