Warum ist meine Web-Anwendung Latenz zu sehen?

Question

Wir haben eine ASP.Net-Anwendung, die seltsam unter IIS6 verhält. Die App selbst ist unkompliziert ASP.Net 2.0 Webforms viel, nichts zu seltsam ist dort auf dem Gehen (es paar HTTP-Module in der Pipeline ist, aber ich würde nicht diese seltsame :) betrachten). Das, was ich nicht verstehe, ist die Seite Ausführungszeiten, oder, genauer gesagt, die Differenz zwischen der von ASP.Net berichteten Zeitverfolgung (trace.axd) und durch den Client (Fiedler) beobachtet. Wenn die App auf dem Entwickler-Box (WinXP, IIS5.1) ausgeführt wird, sind die Zeiten, berichtet von ASP.Net und Fiddler ganz in der Nähe:

Page exec time             :  0.0919834
Fiddler Total Sequence time:  0.1560980 

kann ich verstehen, 60ms ausgegeben werden 5KB im Wert von Daten von IIS zu Fiddler bekommen (die beide auf der gleichen Maschine laufen, BTW). Nun, wenn wir den Code an den Server (Win2k3, IIS6) bewegen, ändert sich das Bild dramatisch:

Page exec time             :  0.1702014
Fiddler Total Sequence time:  0.5156283 

Dies ist die gleiche Seite, und Fiddler wieder mit dem Code auf der gleichen Maschine laufen. Warum es plötzlich 350ms nimmt die gleiche 5KB zu liefern?

PS. Auf beiden Maschinen werden die Ergebnisse durch den Zugriff auf die URL über die reale Maschine Hostnamen erhalten, z.B. http: //machinename/app/page.aspx (im Gegensatz zu http: //localhost/app/page.aspx ).

PPS. Configuration-weise, die Setups eines Dev-Box und dem Server sind so nah, wie wir sie machen könnten - beide verwenden exakt die gleichen web.config. Beide schlugen die DB (SQL-Server) mit integrierten auth und folglich die Anwendung unter einem Domänenkonto ausgeführt wird. Die App nutzt die Formularauthentifizierung und hat sich nicht als (das heißt es immer unter demselben Konto ausgeführt wird). Nun wird die Art und Weise dies auf IIS5 arbeitet unterscheidet sich von IIS6 - auf IIS5 das Konto angegeben in-Tag in der machine.config und auf IIS6 ist es die AppPool Einstellung. Das Setup scheint ziemlich typisch für beide Umgebungen, und ich kann es mir nicht vorstellen 350ms Verzögerungen verursacht ...

Answer 1

Nach einer der wenigen kostbaren Supportfälle aufwendet wir mit unserem MSDN-Abonnement haben, weiß ich endlich die richtige Antwort auf „wo ist die ganze Zeit verbracht“ Frage. Kurz gesagt, wird die Zeit in HTTP-Module haben wir in unserer Pipeline haben. Die Zeitmessungen berichtet von ASP.Net Trace.axd Datensatz nur die Zeit, in der ASPX-Seite ausgegeben selbst, Module sind nicht enthalten.

Eine einfache Möglichkeit, dies zu ermitteln (und zu sehen, wie lange dauert jedes Modul, um seine Sache zu tun) ist die ETW verwenden (Event für Windows Tracing). Hier ist die Erklärung (ich vermute stark, dass dieser Beitrag geschrieben wurde, nachdem sie in unserem Fall sah :)) eine Sache, die ich an die ausgezeichnete Beschreibung oben hinzufügen kann, ist, dass ich die SvcTraceViewer statt LogParser die Trace-Ausgabe zu analysieren.

Update: der obige Ansatz funktioniert auch auf Windows Server 2008, nur sicherstellen, dass Sie Tracing installiert .

Answer 2

Führen Sie eine Trace-Route auf der URL Sie sie fordern und vergleichen. Ich wette mit dem Entwickler Maschine, die Sie im Inneren der Maschine bleiben, aber auf der Produktionsmaschine Sie gehen extern und dann kommt wieder in durch die IP-Adresse.

Ist dies der Fall, versuchen Sie, diese zu Ihrer Host-Datei (c: \ windows \ system32 \ drivers \ etc \ hosts

www.mysite.com    127.0.0.1

Dies wird sicherstellen, dass Ihre Anfrage nicht außerhalb der Maschine nicht wagen, den Antrag zu machen. Sie sollten die Antwortzeiten sehen zu beginnen, miteinander in Einklang zu kommen.

Aktualisieren

das neue Updates gegeben. Wenn der Server unter Last ist, während der Produktion zu testen könnte dies für den Unterschied ausmacht, weil es aktiv versucht, mehr Anfragen als die Entwicklungsmaschine zu liefern, die nur versuchen 1. zu liefern

Oder es könnte sein, weil Sie zwei verschiedene Versionen von IIS zu testen sind, 5.1 auf XP und 6.0 auf 2003 wirklich nicht für die Unterschiede, es sei denn die beiden Umgebungen ausmachen können, sind mit der gleichen Software ausgeführt wird.

Answer 3

Ist die App auf beiden Boxen in identischen Release-Konfigurationen ausgeführt wird?

EDIT: Die Pipeline Anfrage verändert enorm zwischen IIS5 und IIS6, trace.axd wird nur den ASP.NET Teil davon zu sehen, nicht den neuen App-Pool und HTTP.SYS Komponenten

.

Ich könnte mir vorstellen, dass die Konfiguration kann ein bisschen auf IIS6 eingestellt werden, aber Sie werden wahrscheinlich den Unterschied einer leichten, nicht Produktion Webserver (IIS5) und einem robusten Webserver mit einzelnen Anwendungspools zu verwalten und mehr Abstraktionsebenen suchen.