Wie erreicht man eine gute Web-Performance? Nun, am besten durch Tuning und Nutzung der neuen IIS 8.5 Möglichkeiten und durch … Testen. Es gibt hierzu viele Werkzeuge, eines haben Sie aber ganz bestimmt auf Ihrem Windows-Rechner: den Internet Explorer. Mit Windows 8.1 kommt standardmäßig IE11 mit. Dieser eignet sich vorzüglich dazu, das Ladeverhalten von Websites zu testen.
Testen des Ladeverhaltens einer Webseite
In Teil 3 unserer IIS und Web-Serie haben wir die neue IIS 8.5 Funktion “Idle Worker Process Page-out” kennengelernt. Diese Leistungssteigerung mit dem Suspend-Modus nach Leerlauf sollte natürlich auch gleich getestet werden. Mit IE11 geht das sehr einfach und zwar mit den Developer-Tools mit F12.
Die Testmethode
…ist sehr einfach: In IE11 einmal die Funktionstaste F12 für das Einschalten der Developer-Tools drücken. Nun in das Modul Netzwerk klicken (oder Strg+4). Im Netzwerk auf den Play-Button klicken (oder F5) und die Test-URL öffnen oder die Seite refreshen – sprich die Webseite neu laden. Wenn das Testen beendet werden soll, kann mit Umschalt+F5 der Play-Modus wieder beendet werden.
Using the F12 developer Tools zeigt alle Funktionen der IE11-Developer Tools, diese sind für das Analysieren sehr wertvoll. Die Developer Tools sind übrigens auch in etwas anderer Form in IE10 und IE9 enthalten, siehe IE10 Developer Tools und IE9 Developer Tools.
Die Developer Tools können natürlich noch viiieeel mehr – hier beschränken wir uns allerdings nur auf die Ermittlung der Ladezeit für ein Web.
Das Testszenario
Die Tests erfolgten auf einem Produktivsystem (eine Windows Server 2012 R2-VM auf Hyper-V) mit 55 Webs, 4 CPUs und max. 8 GB dynamischen RAM und herkömmlichen Festplatten (keine SSDs). Als Testwebsites musste eine einfache HTML-Datei (ohne Grafiken und Styles) und ein “richtiges” CMS mit dem Open CMS Umbraco und .NET Framework 4 herhalten. Zum Testen wurde das Idle-Time-out auf nur 1 Minute (statt 20) heruntergesetzt.
Hinweis: Alle angegebenen Ladezeiten können natürlich durch den Client und die ausgeklügelten Caching-Strategien des Browsers verfälscht sein. Der Browser-Cache sollte vor jedem ersten Laden geleert werden. Dennoch, es herrschen keine Laborbedingungen (der Webserver bedient beispielsweise viele weitere Webs) und die Werte geben ein Bild aus der Praxis wieder.
Testen wir nun die IIS 8.5 Funktion Idle Worker Process Page-out:
Statisch-Standard
Zunächst sehen wir uns die Eigenschaften des AppPools des Test-Webs an.
Der ApplicationPool des Webs ist standardmäßig immer auf die Idle Time-out Action mit Wert Terminate gestellt.
Zum Testen habe ich die Idle Time-out (minutes) von 20 auf 1 Minute heruntergestellt (Schritt 3.) und den AppPool restarted, (Schritt 5.). Der Screenshot zeigt alle Schritte vom Markieren des Webs bis zum Recycle des AppPools.
Diese Einstellungen wurden mehrmals für die Tests mit verschiedenen Werten für Idle Time-out Action gesetzt.
In dem Web liegt eine sehr kleine statische HTML-Website (Text only, keinerlei Styles oder Bilder).
Das ersten Öffnen (nach AppPool Recycle) der Webseite dauert etwa 375ms. Weitere Versuche für das erstes Starten nach AppPool Recycle oder Timeout lagen immer zwischen etwa 280 und 375ms - durchschnittlich bei etwa rund 300ms.
Jedes neue Laden braucht in meinem Beispiel dann nur mehr lächerliche 32ms – wenn die Webseite bereits gestartet ist.
Wiederholungen liefern in etwa immer solche Werte – die Webseite kann schnell aus dem Memory ausgeliefert werden.
Nun wollen wir sehen, wie es nach einem Leerlauf (Idle-Timeout) aussieht.
Nach einer guten Minute – das Web muss jetzt terminiert sein – rufen wir nochmals die Webseite auf.
Wohooooo, die Ladezeit der statischen Webseite beträgt nun 328ms – wie beim ersten Start!
Was für ein Unterschied, hier greift cold request.
Das Problem
Das bedeutet, die Website muss nach Leerlauf komplett neu in den Memory-Pool des Worker Process geladen werden (siehe Teil 3). Das ist bei einer statischen Mini-Website mit wenigen hundert Millisekunden Ladezeit zwar noch kein Thema, aber bei dynamischen Webs mit einem großen Framework wie PHP oder .NET darunter kann dieser Prozess schon viele Sekunden dauern!
Wenn die Webseite im Memory des Webservers geladen ist: Jedes neuerliche Laden dauert dann wieder nur etwa 31ms.
Nach dieser Erkenntnis wollen wir die neue Funktion Idle Worker Process Page-out testen.
Statisch-Idle Worker Process Page-out
Nun stellen wir die AppPool-Eigenschaft Idle Time-out Action auf Suspend und recyclen den AppPool.
Das erste neue Laden des Webs dauert nun 187ms - ähnlich wie zuvor bei cold request mit etwa 328ms.
Nachdem eine gute Minute verstrichen ist, öffne ich nochmals die Webseite….
Die Ladezeit der statischen Webseite beträgt nun nur mehr 62ms – statt zuvor 328ms, weniger als ein Fünftel Zeit!
Refreshes sind dann wieder in den üblichen 31ms geladen.
Neuerliche Tests jeweils nach dem Timeout von 1 Minute liefern wieder ähnliche Werte, zwischen etwa 60 und 100ms. Die Idle Worker Process Page-out Funktion greift und liefert die Webseite wesentlich rascher aus.
Statisch-Fazit
Damit ist das Laden von statischen Websites mit aktivierter Idle Worker Process Page-out Funktion in der Praxis etwa um den Faktor 3 bis 5schneller als ohne diese Funktion! Es zahlt sich also aus, sie einzusetzen.
Wie sieht es nun bei “echten” Webs mit dynamischem Inhalt aus?
Dynamisch-Standard
Zum Testen wird das OpenSource CMS Umbraco mit einem SQL Server (auf einer eigenen Maschine) mit einer heutzutage üblichen Website verwendet und zwar nur die Startseite. Als Domäne wird dieselbe wie zuvor verwendet. Das Web läuft auf .NET Framework 4.0.
Der erste Aufruf des Webs dauert 5.95s. Bei mehreren Versuchen für das erste Laden waren Werte zwischen etwa 4s und 6s zu erreichen.
Jedes neue Laden dauert etwa 0,65s. Das Verhältnis der HTTP-Requests verschiebt sich, das Aktualisieren der Webseite dauert am längsten. Bei mehreren Versuchen waren so Ladezeiten zwischen 0,6s bis zu etwa 1s drin.
Nach Leerlauf und Terminate wird das Web erneut aufgerufen. Das sieht dann so aus:
Das Web benötigt 4,35s um neu zu starten, ähnlich wie zuvor beim ersten Start.
Nun sehen wir uns das Ladeverhalten wieder mit aktivierter Idle Worker Process Page-out Funktion an.
Dynamisch-Idle Worker Process Page-out
Wie oben mit der statischen Website wird der AppPool wieder von Terminate auf Suspend gestellt und recyclet.
Das erste Laden unterscheidet sich nicht von unserem Ergebnis zuvor, etwa 6s.
Nun wird wieder eine gute Minute gewartet und das Web nach dem Leerlauf erneut aufgerufen. Das Ergebnis sieht so aus:
Nach dem Erwachen des Webs mit Suspend dauert das Laden 0,81s. Somit ist dies eine wesentlich bessere Ladezeit als nach Terminate!
Mit Suspend wird das Web in 0,81s statt in 4,35s geladen, das entspricht wieder einer geringeren Ladezeit um den Faktor 5,3!
Zur Vollständigkeit: Bei mehreren Test wurden so Ladezeiten zwischen 0,81 und 1,25s erreicht, das wäre Faktor 5,3 bis 3,5. Zumeist wurde der kleinere Wert erreicht, somit liegt unser Faktor bei durchschnittlich 5x schneller.
Dynamisch-Fazit
Gerade bei dynamischen Webseiten bringt die aktivierte Funktion Idle Worker Process Page-out in der Praxis eine Beschleunigung meist etwa um den Faktor 5! Je größer und komplexer die Website, desto größer ist der zu erwartende Zeitgewinn nach einem Leerlauf und Reaktivierung des Webs.
Gesamt-Fazit
Die neue Funktion Idle Worker Process Page-out in IIS 8.5 bringt erhebliche Ladezeit-Verbesserungen. Sie ist standardmäßig nicht eingeschalten und sollte aus meiner Sicht aktiviert werden.
Technisch funktioniert die Verbesserung durch ein Page-Out des Memories eines Worker Process (Web) auf die Festplatte. Bei neuerlichen Zugriffen nach einem Leerlauf (Timeout) wird der gespeicherte Zustand in das Memory geladen. Dieser Vorgang ist wesentlich schneller als die Neuinitialisierung eines Webs, somit kann der Webserver die Website um ein Vielfaches schneller ausliefern. Bei unseren Tests konnten wir eine verbesserte Ladezeit von mindestens etwa Faktor 5 erreichen.
Hier eine Tabelle mit den ersten Test-Werten aus unserem Demo zum direkten Vergleich:
Webseite | 1.te Ladezeit | 1.te Ladezeit | Faktor |
Statisch | 325ms | 62ms | 5,2 |
Dynamisch (.NET) | 5,95s | 0,81s | 7,3 |
In unseren Demos waren die Webseiten meist schon nach etwa 1s geladen, statt erst nach 5s - also eine sehr stark verbesserte Usability. Bei größeren Website-Systemen wird die Leistungssteigerung wahrscheinlich noch höher sein. Ein Einsatz von Solid State Disks (SSD) wird diesen Effekt nochmals spürbar verbessern.
Hinweis für Developer: Unser Team wird in codefest.at ein kleines Sample posten, wie man App Suspend für Web Applications in einer Windows Azure Web Role aktivieren kann.
Somit unser Tipp: In IIS 8.5 Idle Worker Process Page-out einschalten. Wir haben bislang keine nachteiligen Effekte in der Praxis bemerkt.
Viel Spaß bei Pimp-your-Website (after Idle Timeout)!
Artikelserie, siehe auch
- IIS und Web Teil 1–Neuerungen und Installation von IIS 8.5
- IIS und Web Teil 2-Verbessertes Logging in IIS 8.5
- IIS und Web Teil 3-Verbesserte Performance mit IIS 8.5
- IIS und Web Teil 4-Web-Performance testen