IIS-Performance

Die IIS (Internet Information Services) wurden beim Windows Server 2003 grundlegend überarbeitet, um eine höhere Leistungsfähigkeit zu erzielen. Welches die wichtigsten Maßnahmen zur Performanceoptimierung für die IIS 6.0 sind, erfahren Sie im vorliegenden Beitrag.

Das neue Prozessmodell der IIS 6.0 erleichtert die Performance-Optimierung, da der zentrale Prozess inetinfo.exe nicht mehr denselben Engpass bildet wie in früheren Releases. Die Ausführung der Kernfunktionen und von ergänzenden Anwendungen, die über die Schnittstelle ISAPI (Internet Services API) arbeiten, erfolgt nun in getrennten Arbeitsprozessen (Worker Processes). Die HTTP-Anforderungen werden wiederum im Kernel Mode von einem speziellen Listener empfangen und an die jeweiligen Arbeitsprozesse weitergeleitet.

Bei der Performance-Optimierung der IIS 6.0 geht es daher nun darum,

  • die richtige Anzahl an Arbeitsprozessen zu konfigurieren,

  • die einzelnen Arbeitsprozesse zu optimieren und

  • die Kernel-Mode-Komponente http.sys so anzupassen, dass sie die optimale Leistung bietet.

Das macht die Optimierung der Performance im Vergleich mit der Vorversion etwas komplexer, weil es mehr Stellschrauben gibt. Dafür ist die Zahl der Optionen höher, um die Performance von Webservern auf Basis der IIS zu verbessern.

Generelle Parameter

Es gibt eine Reihe von Registry-Parametern, die für die IIS angepasst werden können. Eine Übersicht darüber findet sich im Whitepaper „Performance Tuning Guidelines for Windows Server 2003“. Außerdem wurden verschiedene Parameter auch schon im Artikel „Performance Tuning beim Windows Server 2003“,Teil 3, in Heft 10/2005 (Seite 2588) erläutert und werden deshalb hier nicht weiter besprochen.

Die Optimierung von Anwendungspools

Einstellungen lassen sich auch an der Oberfläche vornehmen. Zunächst kann bestimmt werden, ob und mit welchen Anwendungspools gearbeitet wird und welche Anwendungen und Arbeitsprozesse welchem dieser Pools zugeordnet werden. Die Grundregel ist, dass mit getrennten Pools gearbeitet werden sollte, wenn Anwendungen unterschiedliche Anforderungen an die Konfiguration stellen oder Ressourcen für eine Anwendung begrenzt werden sollen. Die meisten IISbasierenden Anwendungen von Microsoft sind so konfiguriert, dass sie mit einem eigenen Anwendungspool arbeiten. In einzelnen Fällen wie bei den WRM (Windows Rights Management Services) werden aber auch mehrere Pools verwendet.

Bei den Eigenschaften des Knotens Anwendungspools finden sich zwei Register, die für die Performance-Optimierung relevant sind. Im Register Wiederverwendung legt man fest, wie die Arbeitsprozesse in einem Anwendungspool genutzt werden sollen. Dabei geht es nicht darum, einen bestehenden Prozess für eine andere Aufgabe weiter zu verwenden, sondern darum, Prozesse durch einen neuen Prozess zu ersetzen, um Fehler, die im Laufe der Zeit auftreten, zu minimieren. Die Übersetzung in diesem Register ist insofern nicht ganz glücklich.

Arbeitsprozesse lassen sich nach einer definierten Zeit, nach einer festgelegten Anzahl von Anforderungen, nach einem Zeitplan oder beim Erreichen von definierten Speicherobergrenzen neu starten. Der Ersatzprozess wird parallel gestartet, während der bisherige Arbeitsprozess noch die ausstehenden Anforderungen bearbeitet.

Bild 1: Das Register Wiederverwendung bei den Eigenschaften von Anwendungspools
Bild 1: Das Register Wiederverwendung bei den Eigenschaften von Anwendungspools

Auf die Performance wirkt sich dieses Konzept kurzzeitig negativ aus, da es zwei parallele Prozesse gibt. Da potenzielle Fehler in Anwendungen wie Memory Leaks – also einem kontinuierlich steigender Verbrauch an Speicherressourcen – aber in ihren Auswirkungen begrenzt werden, ergibt sich daraus insgesamt gesehen eine geringere Last im System.

Das zweite Register im Zusammenhang mit der Performance-Optimierung von Anwendungspools ist Leistung, wo beispielsweise ein Zeitlimit für den Leerlauf von Arbeitsprozessen konfiguriert werden kann. Mit der Option Begrenzung für Anforderungswarteschlange sorgt man dafür, dass nicht zu viele Anforderungen ausstehen dürfen. Die Kernelkomponente, also http.sys, sendet in diesem Fall den Fehler 503 an die Clients. Mit dieser Option wird verhindert, dass zu lange Warteschlangen entstehen, die von den Arbeitsprozessen nicht abgearbeitet werden können. Falls diese Situation wiederholt auftritt, sollte allerdings die Konfiguration des Servers angepasst werden, um eine ausreichend schnelle Verarbeitung der Anforderungen sicherzustellen.

Man kann auch eine CPU-Überwachung aktivieren, um einem Anwendungspool nur einen begrenzten Anteil der CPU-Kapazität zuzugestehen. Da die Aktionen in diesem Fall aber sehr begrenzt sind, bringt diese Option wenig.

Bild 2: Das Register Leistung für die Konfiguration von Anwendungspools.
Bild 2: Das Register Leistung für die Konfiguration von Anwendungspools.

Schließlich kann bei Webgarten – wieder eine etwas eigenwillige Übersetzung – auch noch die maximale Anzahl der Arbeitsprozesse für den Anwendungspool angegeben werden. Eine höhere Anzahl von Arbeitsprozessen ist für die Lastverteilung vor allem in Mehrprozessor-Systemen interessant.

Im Register Zustand stehen noch einige interessante Optionen bereit, mit denen unter anderem ein relativ schneller Start von Arbeitsprozessen festgelegt werden kann. Die gleichen Optionen findet man auch bei den einzelnen Anwendungspools. Die generellen Optionen gelten für alle neuen Anwendungspools, soweit dort keine speziellen Anpassungen vorgenommen werden.