Windows Server 2012 R2 und IIS 8.5 bringen zwei coole neue Funktionen zur Verbesserung der Web-Leistung. Für viele Websites beschleunigt Dynamic Site Activation das Laden der Webs und die neue Einstellungen Idle Worker Process Page-out wirkt als Performance-Boost nach Web-Leerlauf. Bevor wir in die Details gehen, sehen wir uns noch kurz die Architektur von IIS an, um zu verstehen, worin jetzt die Optimierungen liegen. Ein Blick in die IIS-Geschichte von Windows zeigt uns die geänderte Architektur.

IIS und WAS

In IIS6 (Windows Server 2003) werden alle Anfragen von einem Listener Process (einem long-running Windows NT service) und einem Worker Process verarbeitet. Der Listener Process wartet auf HTTP(S)-Nachrichten und reicht diese an einen passenden (über die URI verbundenen) Worker Process w3wp.exe weiter, der den Application Code für die Anfrage ausführt.

Diese Architektur wurde ab IIS 7 (Windows Server 2008) geändert. Windows Process Activation Service (WAS) ist ein neues Feature von IIS. Damit werden Windows Communication Foundation (WCF) Services gehostet, ohne das ganze IIS Paket zu verwenden (bzw. auch ohne IIS installiert zu haben).

Vereinfacht gesagt bedeutet das, WAS hostet Webservices für Nicht-HTTP Szenarien wie TCP, Named Pipes und MSMQ für service-based Applications über SMSvcHost.exe. IIS verarbeitet Webdienste, die über das HTTP oder HTTPS-Protokoll laufen - sprich über den HTTP stack und HTTP.sys als Protocol Listener und das WWW Service.

Der W3SVC-Process bleibt in seiner Rolle als HTTP Listener, jedoch befinden sich die Komponenten für Konfiguration und Process Activation in WAS. WAS besteht aus drei Teilen: dem Configuration Manager, dem Process Manager und dem Listener Adapter Interface.

Wer tiefer gehen möchte, dem empfehle ich die Artikel IIS WAS Configuration , Inside WAS, Benjamin Perkins MSDN Blog sowie die IIS-Versionen Wikipedia Seite.

Dynamic Site Activation

Wenn in IIS vor Version 8.0 - also IIS 6, 7 oder 7.5, das entspricht Windows Server 2003, 2008 oder 2008 R2 - viele (mehr als 100) Websites gehostet werden, kann es länger dauern, bis IIS das Konfigurationsfile laden kann, WAS lädt die Konfiguration für alle Websites auf dem Server. Bei Problemen oder Fehlern wurden die entsprechenden Aktionen nicht mehr ausgeführt.

WAS erzeugt für jede Website und jedes Binding eine eigene Queue und arbeitet diese für jeden Request ab, registriert das Binding und startet den Worker Process für die Site.

In IIS 8.5 (und auch teilweise in IIS 8.0) wurde dieser Ladevorgang optimiert, um die Leistung dieses Dienstes zu steigern. Dies passiert durch verbessertes Memory-Management und durch einen einzelnen Ladevorgang in eine Queue durch WAS (“single catch-all request queue” anstatt je einem pro Eintrag, was zu tausenden einzelnen Requests in Http.sys führen kann). Dieser Vorgang heißt Dynamic Site Activation.

Bei weniger als 100 Websites bzw. Bindings auf dem Webserver wird jedoch – genauso wie zuvor - der Standard-Ladeprozess verwendet, da bei einer solch geringen Anzahl aufgrund der Größe des Konfigurationsfiles kaum Probleme zu erwarten sind.

Der Vorteil der Dynamic Site Activation wird somit erst bei einer großen Anzahl Websites und Bindings (>100) verwendet und spürbar. Das Feature selbst ist nicht über eine GUI verwaltbar, aber das Limit kann über ein dynamicRegistrationThreshold attribute in IIS 8.5 eingestellt und gesteuert werden.

Dazu öffnen Sie im IIS im Knoten des Webservers den Configuration Editor.

SNAGHTML1d95259

…und im Editor-Modul die Section system.applicationHost/webLimits. Hier kann das Setting dynamicRegistrationThreshold mit dem Standardwert 100 verändert werden. WAS muss restarted werden, damit die neue Einstellung greift.

image

Mehr Informationen über WAS-Internas finden Sie u.a. im kostenfreien eBook von MS-Press Free ebook: Introducing Windows Server 2012 R2 Preview Release ab Seite 81.

Nach der Theorie nun zur Praxis und dem Beschleunigen von beendeten Webs.

Idle Worker Process Page-out

Wenn eine Website länger als 20 Minuten nicht verwendet wird, terminiert IIS den Worker Process um Ressourcen (Memory) zu sparen. Auch wenn man das Timeout einstellen kann, führt eine Nicht-Verwendung irgendwann zum Beenden des Webs. Die erste Anfrage an ein noch nicht gestartetes Web wird als cold request bezeichnet. IIS muss initialisiert werden, das entsprechende Framework (etwa .NET oder PHP) muss initialisiert werden, die Website muss initialisiert werden usw. Das alles kostet Zeit.

Statische Websites benötigen üblicherweise ein paar hundert Millisekunden zum Starten. Dynamische Websites brauchen jedoch oft viele Sekunden bis sie laufen, da ihr Framework zuerst neu in den Worker Process geladen werden muss, welches dann den Code ausführt. Daher wurde in IIS 8 (Windows Server 2012) eine Application Initialization eingebaut, die es dem Administrator erlaubt, das Application Framework vorab zu laden. Das kostet jedoch viel Speicher. Auf einem Server mit hunderten Websites und durchschnittlich mindestens 100MB pro Framework kann das rasch zu einem Engpass führen - also nicht immer die beste Methode für Web-Optimierung.

In IIS 8.5 gibt es nun die Möglichkeit, einen Worker Process nach Leerlauf nicht zu beenden (terminieren), sondern ihn nur zu unterbrechen (suspend). Diese Funktion heißt Idle Worker Process Page-out. Dabei wird der Worker Process vom Speicher auf die Festplatte gespeichert (data paging) und aus dem Memory entfernt. Durch den Einsatz von solid state disk (SSD) kann die Leistung weiter gesteigert werden.

Hierfür kann das neue Attribut Idle Time-out Action (idleTimeoutAction) pro Application Pool von Terminate auf Suspend gesetzt werden.
Mit der Idle Time-out (minutes) Eigenschaft wird die Dauer des Leerlaufs vor dem Abschalten (Standard 20 Minuten) eingestellt.

image

Standardmäßig ist Idle Worker Process Page-out in IIS 8.5 nicht aktiviert, sondern Worker Processes werden terminiert.

Daher muss Suspend für die gewünschten Webs eingeschaltet werden und der AppPool recyclet werden.
Wenn der Wert auf Server-Ebene gesetzt wird, gilt dies nicht für die bestehenden AppPools, aber für alle neuen AppPools!

Wenn diese Einstellungen durchgeführt wurden, geht es ans Testen der Web-Leistung. Das machen wir im nächsten Teil!

Artikelserie, siehe auch