IIS 7.0
Die 10 wichtigsten Leistungsverbesserungen in IIS 7.0
Mike Volodarsky
Auf einen Blick:
- Minimieren des Speicherbedarfs Ihrer Anwendungen
- Senken der Bandbreitenkosten
- Verwenden verbesserter Zwischenspeicherfunktionen
Inhalt
Schlankere Webserver
Schlankes Betriebssystem als Basis
Spezialisierte Anwendungstopologien
Verbesserte Anwendungsunterstützung
Erhöhen der Anwendungsdichte
Bandbreitenverringerung durch Komprimierung
Einschränken der Medienbitrate
Ausgabezwischenspeicherung
Konvertieren von ISAPI-Code in IIS 7.0-Module
Servererweiterbarkeit
Zusammenfassung
Wenn ich mich mit Vertretern von Unternehmen treffe, die die Einführung von IIS 7.0 planen, werde ich unweigerlich gefragt, ob durch die Umstellung auf IIS 7.0 die Leistung von Servern oder Anwendungen verbessert wird. Die
Antwort lautet in der Regel: „Ja, aber Sie sollten nicht überrascht sein, wenn sich bei der erstmaligen Migration Ihrer Anwendungen nach IIS 7.0 keine Leistungsverbesserungen einstellen.“
Um dies nachvollziehen zu können, müssen Sie das Wesen der aktuellen Version verstehen. IIS 6.0 war eine Entwicklungsversion, die auf das Erreichen von drei Zielen ausgerichtet war: stärkere Sicherheit, höhere Zuverlässigkeit und bessere Leistung. IIS 7.0 ist hingegen eine Plattformversion. Ihr Zweck bestand darin, den qualitativ hochwertigen grundlegenden Webserverkern der Vorgängerversion in eine modulare und erweiterbare Plattform mit Unterstützung für wichtige moderne Bereitstellungs- und Verwaltungsszenarios umzuwandeln.
Viele der architektonischen Änderungen und neuen Features können sich tatsächlich negativ auf die Leistung des Webservers auswirken – beispielsweise aufgrund der Tatsache, dass eine der wichtigsten Änderungen darin bestand, dass die streng optimierten Webserver-Codepfade auf eigenständige Module aufgeteilt wurden, die keine spezielle Behandlung vom Webserver erfahren. Dank einer umfangreichen Leistungsoptimierung durch das IIS-Team bietet IIS 7.0 jedoch dieselbe Leistung wie die Vorgängerversion und übertrifft diese sogar in bestimmten Bereichen. Da ich persönlich am Webserverkern und der integrierten Pipeline mitgearbeitet habe, kann ich Ihnen sagen, dass hierzu ein großer Einfallsreichtum beim Entwurf und viel harte Arbeit bei der Implementierung des Produkts erforderlich waren.
Dennoch bietet IIS 7.0 ein viel höheres Potenzial für die Erzielung wesentlicher Leistungsverbesserungen und die Senkung leistungsbezogener Kosten für Ihre Serverfarm als jede andere IIS-Version in der Vergangenheit.
Sie erzielen diese Vorteile nicht unbedingt durch die einfache Migration nach IIS 7.0, einige Umgebungen werden jedoch von ihnen profitieren. So wurde beispielsweise bei Microsoft.com die CPU-Effizienz um 10 Prozent gesteigert. (Die vollständige Analyse finden Sie im Microsoft.com-Teamblog unter go.microsoft.com/fwlink/?LinkId=122497.) Möglicherweise stellen Sie auch deutliche Verbesserungen in bestimmten Bereichen fest, einschließlich SSL- (Secure Sockets Layer) und Windows®-Authentifizierung (beide werden jetzt im Kernel durchgeführt) und besserer vertikaler Skalierbarkeit auf Mehrkern- und Mehrprozessorcomputern.
Dennoch beruht die wahre Leistungsstärke von IIS 7.0 nicht auf inkrementellen Leistungsverbesserungen bei vorhandenen Features, sondern auf neuen Funktionen, die Sie aktiv nutzen sollten. Diese Funktionen basieren häufig auf der Flexibilität und Erweiterbarkeit der Plattform und auf neuen Leistungsfeatures. In diesem Artikel werden 10 der wichtigsten Quellen für die Leistungsverbesserungen beschrieben, die Sie durch den Umstieg auf IIS 7.0 erzielen können.
Schlankere Webserver
Die Möglichkeit zur Bereitstellung schlanker IIS 7.0-Server beruht auf der modularen Architektur des Servers. Praktisch alle Webserverfeatures werden als modulare Komponenten implementiert, die einzeln hinzugefügt oder entfernt werden können. Daher können Sie alle Serverfeatures entfernen, die für den Betrieb einer Anwendung nicht erforderlich sind, was zu bemerkenswerten Vorteilen wie einer wesentlich kleineren Angriffsfläche, geringerem Speicherbedarf und besserer Leistung führt.
Der vollständige Featuresatz für IIS 7.0-Webserver umfasst 44 Module, einschließlich systemeigenen IIS-Modulen und ASP.NET-Modulen, die Dienste für die integrierte Pipeline bereitstellen. Diese Module bieten Dienste wie Authentifizierung (Windows-Authentifizierungs- und Digestauthentifizierungsmodule), Anwendungsframework-Unterstützung (FastCGI-Modul), Anwendungsdienste (Sitzungszustandsmodul), Sicherheit (Anforderungsfilterungsmodul) und Leistung (Ausgabecachemodul). Dennoch kann ein minimaler Webserver, der einfach statische Inhalte bereitstellen muss, mit nur 2 Modulen funktionieren!
Der Mehraufwand durch unnötige Module kann recht groß sein – z. B. im Fall von Modulen zur Anforderungsprotokollierung und zur Ablaufverfolgung für Anforderungsfehler. Das Entfernen solcher Module in Umgebungen, in denen sie nicht benötigt werden, kann zu einem höheren Gesamtdurchsatz und schnelleren Antworten führen, die die TTFB- (Time To First Byte, Zeit bis zum ersten Byte) und TTLB-Metriken (Time To Last Byte, Zeit bis zum letzten Byte) für die Serverarbeitsauslastung verringern.
Abbildung 1 zeigt die Ergebnisse eines einfachen Durchsatztests für eine HTML-Datei (statische Arbeitsauslastung) und eine ASP.NET-Seite namens „Hello World“ (ASP.NET-Arbeitsauslastung) für die Konfiguration mit dem vollständigen Featuresatz, dem Standardfeaturesatz für diese Arbeitsauslastung und dem für die Arbeitsauslastung absolut erforderlichen Mindestfeaturesatz. Obwohl die meisten nicht unbedingt erforderlichen Features bei der vollständigen Konfiguration bereits deaktiviert sind, führt ihre vollständige Entfernung in der Minimalkonfiguration zu einer beträchtlichen Durchsatzsteigerung für die statische Arbeitsauslastung und die ASP.NET-Arbeitsauslastung.
Abbildung 1 Durchsatzraten der statischen Arbeitsauslastung und der ASP.NET-Arbeitsauslastung bei drei verschiedenen Konfigurationen mit 100 gleichzeitigen Clients (zum Vergrößern auf das Bild klicken)
Darüber hinaus können sich Verbesserungen beim Speicherbedarf und eine höhere Websitedichte ergeben, insbesondere in gemeinsamen Hostingumgebungen oder in Fällen, in denen eine Vielzahl von Arbeitsprozessen verwendet wird. Dies wird in der Regel dadurch erreicht, dass in jedem Prozess weniger DLLs geladen werden und alle Speicherzuordnungen während der Modulinitialisierung und Anforderungsverarbeitung entfallen. Abbildung 2 zeigt die Speicherauslastung (private Bytes des IIS-Arbeitsprozesses) beim gleichen Durchsatztest. Obwohl die Verbesserungen bei diesem Beispiel weniger deutlich ausfallen, entsprechen die Steigerungen den Erwartungen, da der Aufwand bei ASP.NET-Anwendungsdomänen im Verhältnis höher als die durch die entfernten Module erzielten grundlegenden Einsparungen ist.
Abbildung 2 Speicherauslastung (private Bytes) der statischen und der ASP.NET-Arbeitsauslastung bei drei verschiedenen Konfigurationen mit 100 gleichzeitigen Clients (zum Vergrößern auf das Bild klicken)
IIS 7.0 bietet durch Modulvorbedingungen eine zusätzliche Kontrolle darüber, welche Module auf der Anwendungsebene aktiviert werden, sowie die Kontrolle über die Modulverwendung auf der Basis der Arbeitsauslastung. Obwohl dies eine erweiterte Konfiguration erfordert, können sich dadurch zusätzliche Vorteile in Multisiteumgebungen oder für Anwendungen ergeben, die mehrere unterschiedliche Arbeitsauslastungen unterstützen.
Ein Wort der Warnung: Es kann schwierig sein, die Funktionen zu ermitteln, die Sie benötigen. Sie müssen nicht nur die zur Unterstützung Ihres Anwendungsframeworks benötigte Mindestfunktionalität, sondern auch alle zusätzlichen Features berücksichtigen, auf die Ihre Anwendung möglicherweise indirekt zurückgreift. Ihre Anwendung kann beispielsweise auf bestimmte Authentifizierungsmethoden angewiesen sein oder auf einer Autorisierungssemantik basieren, die von verschiedenen IIS-Features bereitgestellt wird. In diesem Fall kann die Sicherheit Ihrer Anwendung durch das Entfernen dieser Features beeinträchtigt werden. Desgleichen kann Ihre Anwendung für funktionale oder leistungsbezogene Zwecke auf einige der Module angewiesen sein, in welchem Fall das Entfernen dieser Module zu fehlerhaftem Verhalten oder Leistungsverlusten führen kann.
Schlankes Betriebssystem als Basis
Windows Server® 2008 bietet ebenfalls auf der Betriebssystemebene eine Aufteilung in Komponenten, die Sie zur weiteren Verkleinerung der Oberfläche Ihres Webservers verwenden können. Server Core ist eine Minimalinstallation des Betriebssystems Windows Server 2008 und enthält einen Mindestsatz von zentralen Betriebssystem-Subsystemen. Server Core ist eine ideale Umgebung für schlanke IIS 7.0-Webserver.
Bei der Evaluierung von Server Core sollten Sie jedoch beachten, dass sich bestimmte Einschränkungen auf Ihre Anwendung auswirken können. Server Core bietet keine Unterstützung für Microsoft® .NET Framework, was bedeutet, dass ASP.NET, .NET-Erweiterbarkeit für IIS und IIS-Manager nicht verfügbar sind. Zudem sind für lokale Verwaltungsaufgaben Befehlszeilentools erforderlich, da Microsoft Management Console (MMC) nicht vorhanden ist. Wenn Sie die Aufteilung in Komponenten bei IIS bereits in vollem Umfang nutzen, werden Sie aus der Leistungsperspektive möglicherweise beim Speicherbedarf oder Durchsatz Ihrer unter Server Core ausgeführten Anwendung keinen Unterschied gegenüber einer vollständigen Windows Server-Implementierung feststellen. Dies beruht darauf, dass von IIS und Ihrer Anwendung auf beiden Plattformen die gleiche Arbeit durchgeführt wird. Es gibt jedoch einen Aspekt, bei dem Sie einen Unterschied bemerken werden: beim Gesamtspeicherbedarf des Servers, sowohl im Hinblick auf den Speicherplatz als auch auf die Speicherauslastung.
Als Beispiel wird in Abbildung 3 der Unterschied beim Speicherbedarf nach der Durchführung des Tests für die statische Arbeitsauslastung bei einer vollständigen Windows Server 2008-Konfiguration und unter Server Core gezeigt. Während der IIS-Speicherbedarf in beiden Fällen praktisch identisch ist, ermöglicht es der niedrigere Betriebssystem-Gesamtspeicherbedarf von Server Core, die Arbeitsauslastung mit wesentlich weniger Speicher zu unterstützen. Der geringere Speicherbedarf kann es Ihnen tatsächlich ermöglichen, Ihre Anwendung auf weniger leistungsfähiger Hardware bereitzustellen und sich dabei auf den Verarbeitungsbedarf der Anwendung und nicht der Betriebssystemumgebung zu konzentrieren. Natürlich ist Server Core dadurch eine hervorragende Wahl für virtualisierte Umgebungen.
Abbildung 3 Speicherbedarf der vollständigen Windows Server 2008-Konfiguration im Vergleich zu Server Core nach der Durchführung des Tests für die statische Arbeitsauslastung (zum Vergrößern auf das Bild klicken)
Spezialisierte Anwendungstopologien
Bei der Optimierung im Hinblick auf die Arbeitsauslastung von Anwendungen können Sie die Arbeitsauslastung in verschiedene Teile aufteilen. Anstatt Ihre Anwendung beispielsweise in einer Farm von 30 identischen Webservern auszuführen, können Sie sie auf 10 Webservern, 5 Anwendungsservern und 3 Proxyservern ausführen, die die Zwischenspeicherung und Komprimierung übernehmen.
Diese Spezialisierung funktioniert aus mehreren Gründen. Zunächst einmal hängt die Leistung vieler Anwendungen stark von verschiedenen freigegebenen Ressourcen wie z. B. dem Arbeitsspeicher ab, die von mehreren Teilen der Anwendung gleichzeitig beansprucht werden können. Der Wettbewerb um diese Ressourcen kann zu Engpässen führen, die verhindern, dass die einzelnen Server in Bezug auf andere Ressourcen vollständig genutzt werden. Durch die Trennung von Teilen der Anwendung erhalten diese Teile problemlos Zugriff auf die andernfalls gleichzeitig beanspruchten Ressourcen, was in Bezug auf den gleichen Satz von Hardwareressourcen zu höherer Effizienz führt.
Darüber hinaus kann es die Spezialisierung der Anwendung ermöglichen, eine größere Cachelokalität zu erreichen und dadurch die Leistung zu verbessern. Hierzu gehören untergeordnete Caches wie der Übersetzungslookaside-Puffer (Translation Lookaside Buffer, TLB) für virtuellen Arbeitsspeicher, der Dateisystemcache und andere Betriebssystem- und Anwendungscaches. Eine weitere Quelle für Lokalitätsgewinne ist die CPU. Wenn die Anzahl der parallel stattfindenden Aktivitäten durch Konzentration auf nur einen bestimmten Teil der Anwendung verringert wird, kann die Anwendung die Zahl der Kontextwechsel reduzieren und die von der CPU durchgeführte Arbeit maximieren.
Des Weiteren ermöglicht die Spezialisierung die arbeitsauslastungsspezifische Optimierung, wodurch jeder Teil der Anwendung effizienter arbeitet. Viele dieser Optimierungen sind aufgrund der widersprüchlichen Anforderungen von verschiedenen Teilen der Anwendung nicht möglich, wenn die gesamte Anwendung auf demselben Server unterstützt wird.
Dies kommt bei der Threadingkonfiguration von IIS und ASP.NET häufig vor, die sich wesentlich auf die Parallelität auswirkt und die Speicherauslastung, die Wartezeit und den Durchsatz für viele Anwendungen indirekt beeinflusst. Die statische Dateiarbeitsauslastung von IIS ist hochgradig asynchron und erfordert ein hohes Limit für gleichzeitige Anforderungen, kommt jedoch mit sehr wenigen verfügbaren Threads aus. Dagegen sind viele der ASP.NET-Features synchron, führen zu einer langen Blockierung und erfordern eine hohe Threadzahl, während andere ASP.NET-Features wiederum ein niedrigeres Parallelitätslimit erfordern, um die Auswirkungen auf den Arbeitsspeicher zu verringern. Durch die Trennung der statischen Arbeitsauslastung und die Aufteilung von Teilen der Pipeline für die Anforderungsverarbeitung auf einen separaten Prozess oder Server können Sie die Parallelität jeder einzelnen Arbeitsauslastung optimieren.
Die Spezialisierung kann zudem eine bessere allgemeine Skalierbarkeit ermöglichen, indem es der Anwendung gestattet wird, separate Arbeitsauslastungen oder Anwendungsteile unabhängig voneinander zu skalieren. Dadurch kann die Anwendungstopologie erhöhte Kapazität und Redundanz genau dort bereitstellen, wo dies am dringendsten erforderlich ist, und Sie müssen nicht auf die gesamte Anwendung die gleiche Vorlage anwenden. Bei diesem Modell kann es sich bei den spezialisierten Ressourcen um physische Server, virtuelle Server oder sogar um Anwendungspools auf demselben Computer handeln.
Bei der Evaluierung der potenziellen Vorteile der Spezialisierung in Ihrer Anwendungstopologie sollten Sie zuerst die verarbeitungs- oder ressourcenintensiven Engpässe in Ihrer Anwendung aufspüren. Diese Bereiche sollten die ersten Kandidaten für die Spezialisierung sein, weil sie ein beträchtliches Optimierungspotenzial bieten können, wenn sie isoliert werden, und weil sie die größte horizontale Skalierung erfordern. Beurteilen Sie dann, ob durch ihre Isolierung die übrigen Teile der Anwendung die Ressourcen effektiver nutzen können. Abschließend müssen Sie den Mehraufwand bewerten, der durch die Konnektivitätsmethode verursacht wird, die zur Verbindung der isolierten Anwendungskomponenten benötigt wird.
Verbesserte Anwendungsunterstützung
IIS 7.0 bietet erweiterte Unterstützung für Anwendungsframeworks durch FastCGI, ein offenes Protokoll, das von vielen Open-Source-Anwendungsframeworks unterstützt wird, die andernfalls die stabile und hochleistungsfähige systemeigene Integration in IIS möglicherweise nicht unterstützen. Im Gegensatz zum Protokoll für die gemeinsame Gatewayschnittstelle (Common Gateway Interface, CGI), das schon seit langer Zeit von IIS unterstützt wird, bietet FastCGI eine viel bessere Leistung auf der Windows-Plattform. Dies ist in erster Linie auf die wiederverwendbare FastCGI-Prozessarchitektur zurückzuführen, durch die der hohe Prozesserstellungsaufwand auf der Ebene einzelner Anforderungen entfällt, sodass Clients permanente Keep-Alive-Verbindungen nutzen können.
Wenn Sie in IIS Anwendungsframeworks mithilfe von CGI oder einer anderen Methode unterstützen, erreichen Sie durch den Umstieg auf das FastCGI-Protokoll möglicherweise eine bessere Leistung (und in einigen Fällen eine höhere Stabilität).
Das erste Anwendungsframework, bei dem diese Unterstützung genutzt wird, ist PHP. Tatsächlich hat das IIS-Team direkt mit Zend Technologies zusammengearbeitet, um sicherzustellen, dass die FastCGI-Implementierung von IIS in Verbindung mit PHP gut funktioniert und Leistungsverbesserungen im PHP-Framework unter Windows ermöglicht. (Weitere Informationen zu dem Projekt finden Sie im folgenden Beitrag in meinem Blog unter go.microsoft.com/fwlink/?LinkId=122509.) Wenn Sie über eine Mischung aus verschiedenen Webservertechnologien verfügen, zu denen unter IIS ausgeführte ASP- oder ASP.NET-Anwendungen und PHP oder andere mit FastCGI kompatible Anwendungsframeworks gehören, bei denen andere Technologien verwendet werden, können Sie diese Anwendungen möglicherweise auf der IIS 7.0-Plattform konsolidieren.
Durch die Umstellung von PHP und anderen Anwendungsframeworks auf IIS 7.0 und FastCGI können Sie verschiedene Features von IIS 7.0 nutzen, einschließlich der integrierten ASP.NET-Pipeline. Dies ist eine äußerst praktische Option für die Erweiterung von Anwendungsframeworks mit ASP.NET-Diensten, ohne sie zu ASP.NET zu konvertieren. Gleichzeitig können Anwendungen dadurch unterschiedliche Frameworks für die Zusammenarbeit verwenden. Ein Beispiel dafür, wie mit dieser Methode die Funktionalität vorhandener Anwendungen erweitert und die Leistung verbessert werden kann, ohne Code zu ändern, finden Sie in meinem MSDN® Magazin-Artikel „Erweitern Sie Ihre Anwendungen mit der integrierten ASP.NET-Pipeline“ (unter msdn.microsoft.com/magazine/cc135973.aspx verfügbar).
Erhöhen der Anwendungsdichte
IIS 7.0 umfasst zahlreiche Verbesserungen, die darauf abzielen, die Dichte der Anwendungen zu erhöhen, die auf einem einzelnen Server gehostet werden können. Diese Verbesserungen sind Bestandteil vieler Features, die IIS 7.0 für die Verbesserung der Qualität des gemeinsamen Hostings bietet. Hierzu zählen beispielsweise optimierte Websitebereitstellung und bessere Anwendungsisolation.
Aus der Leistungsperspektive konzentrieren sich die Verbesserungen hauptsächlich auf zwei Aspekte der Erhöhung der Anwendungsdichte – die Erhöhung der Anzahl der Anwendungen, die auf einem IIS 7.0-Server bereitgestellt werden können, und die Erhöhung der Anzahl der Anwendungen, die jeweils aktiv sein können.
Beachten Sie, dass IIS 7.0 es ermöglicht, auf jedem Server mehr Anwendungen als je zuvor bereitzustellen – bei einigen internen Tests waren bis zu 100.000 Websites auf einem einzelnen Server möglich. Dies beruht auf der Möglichkeit, eine Vielzahl von Websites und Anwendungen zu erstellen und zu konfigurieren.
Ein Wort der Warnung: Um eine schnelle Bereitstellung zu erreichen, müssen Sie auf die neuen Konfigurations-APIs umstellen, da dies mit älteren Konfigurations-APIs nicht möglich ist. Zudem bieten nicht alle Konfigurations-APIs von IIS die gleichen Leistungsmerkmale. Daher ist zur Gewährleistung einer hohen Leistung eine sorgfältige Auswahl erforderlich. Entscheiden Sie sich im Zweifelsfall für Konfigurationsoptionen, bei denen die neuen IIS-Konfigurationsobjekte direkt genutzt werden, einschließlich des Microsoft.Web.Administration-Namespace, des Befehlszeilentools „AppCmd.exe“ und der COM-Konfigurationsobjekte von IIS, auf die über Skripts, .NET oder C++-Code zugegriffen wird.
Wie viele Websites bereitgestellt werden können und wie viele aktiv sein können, ist in der IIS-Architektur, bei der permanente Anwendungen und Arbeitsprozesse zur Anforderungsverarbeitung verwendet werden, ein sehr wichtiger Unterschied. Bei diesem Modell beanspruchen aktive Anwendungen mehr Ressourcen auf dem Server, bieten jedoch auch durch Zwischenspeicherung und entfallende Initialisierungskosten eine bessere anhaltende Leistung.
Da jede aktive Anwendung eine bestimmte Speichermenge und einen separaten Arbeitsprozess erfordert (wenn das empfohlene Anwendungsisolationsmodell verwendet wird), hängt die Anzahl der aktiven Anwendungen stark vom Speicherbedarf der Anwendungen ab. Während eine einzelne Anwendung, die nur statische Inhalte bereitstellt, möglicherweise nur 3 MB für ihren Arbeitsprozess benötigt (und sogar den gleichen Arbeitsprozess mit anderen Anwendungen mit statischem Inhalt gemeinsam verwenden kann), können einige dynamische Anwendungen selbst bei geringer Auslastung 100 MB RAM oder mehr erfordern. Daher ist bei der Definition der maximal möglichen Dichte der Speicheraufwand des IIS-Arbeitsprozesses im Vergleich zum Speicherbedarf der Anwendung unbedeutend.
In einem typischen gemeinsamen Hostingszenario ist häufig eine so genannte 80/20-Verteilung anzutreffen, bei der 80 Prozent der Anforderungen an 20 Prozent der Websites gesendet werden. Dies führt dazu, dass jeweils nur ein kleiner Prozentsatz der Websites aktiv ist. Um eine höhere Anzahl von aktiven Websites zu ermöglichen, bietet IIS 7.0 die aktive Lebensdauerverwaltung. Diese kann Ihnen dabei helfen, von inaktiven Anwendungen belegten Arbeitsspeicher freizugeben, damit mehr aktive Anwendungen gehostet werden können.
Mit IIS 7.0 wird ein neuer Algorithmus namens „dynamischer Leerlauf“ eingeführt, durch den die Leerlauftimeouts von Arbeitsprozessen auf der Basis des auf dem Server verfügbaren Speichers proaktiv angepasst werden. Wenn die Speicherkapazität nahezu erschöpft ist, werden im Leerlauf befindliche Anwendungen schneller entfernt, wodurch mehr aktive Anwendungen gehostet werden können. Ist jedoch genügend Arbeitsspeicher verfügbar, können die Timeouts groß bleiben, um eine bessere Leistung zu ermöglichen und den Anwendungszustand beizubehalten. Der dynamische Leerlauf ermöglicht es nicht nur, dass mehr Anwendungen aktiv sind, sondern er trägt auch zur Vermeidung von Bedingungen mit unzureichendem Arbeitsspeicher bei, die aufgrund von Überlastung zu einem starken Leistungsabfall führen.
Um das Hosting zahlreicher aktiver Anwendungen zu ermöglichen, sollten Sie zudem ein 64-Bit-Betriebssystem verwenden, da das Betriebssystem dann mehr als 4 GB Speicher adressieren kann. Darüber hinaus können Sie die IIS-Arbeitsprozesse für die Ausführung im 32-Bit-Modus (SysWoW64) konfigurieren, in dem sie selbst weniger Speicher belegen, und gleichzeitig dem Betriebssystem ermöglichen, mehr Speicher zu adressieren, als es in einer 32-Bit-Umgebung möglich ist.
Bandbreitenverringerung durch Komprimierung
Es ist nicht überraschend, dass die Bandbreitenkosten zu den höchsten Kosten beim Betrieb eines Datencenters mit Internetverbindung gehören. Darüber hinaus ist die zur Bereitstellung der angeforderten Inhalte erforderliche Bandbreite ein wesentlicher Faktor für die wahrgenommene Reaktionsfähigkeit Ihrer Anwendung.
Eine der effektivsten Möglichkeiten zur Verringerung der Bandbreite, die zur Bereitstellung der Antworten von Anwendungen benötigt wird, besteht in der Verwendung der HTTP-Komprimierung. Dadurch kann die Größe der Antwort wesentlich verringert werden, häufig um den Faktor 10, wenn diese Methode auf leicht komprimierbare Textinhalte wie HTML angewendet wird. Das Beste daran ist, dass nahezu alle Desktopbrowser die HTTP-Komprimierung unterstützen und die Dekomprimierungskosten auf Desktophardware im Vergleich zu den auf dem Senden von weniger Daten beruhenden Wartezeiteinsparungen gering sind. Da die Komprimierung auf der im HTTP 1.1-Protokoll definierten Aushandlung der Inhaltscodierung basiert, kann sie unbedenklich für Clients aktiviert werden, die die Komprimierung nicht unterstützen – diese Clients empfangen einfach eine nicht komprimierte Version der Inhalte.
IIS 7.0 bietet die beiden Komprimierungsfeatures, die mit der Vorgängerversion eingeführt wurden: statische Komprimierung und dynamische Komprimierung. Bei der statischen Komprimierung werden statische Inhalte vorkomprimiert und auf einem Datenträger gespeichert, wodurch bei zukünftigen Anforderungen komprimierte Inhalte ohne Komprimierungsaufwand direkt bereitgestellt werden können. Bei der dynamischen Komprimierung wird die Antwort in Echtzeit komprimiert. Sie ermöglicht daher die Komprimierung für Antworten, die von Anwendungen generiert werden. Die dynamische Komprimierung kann von jedem Anwendungsframework unter IIS 7.0 genutzt werden – einschließlich ASP, ASP.NET und PHP.
Trotz des verbreiteten Mythos ist die dynamische Komprimierung in der Regel nicht mit einem unerschwinglich hohen CPU-Aufwand verbunden. Tatsächlich verursacht die dynamische Komprimierung oft weniger als 5 Prozent der gesamten CPU-Auslastung auf einem ausgelasteten Server. Die dynamische Komprimierung kann relativ großzügig eingesetzt werden, um maximale Bandbreiteneinsparungen für alle Arbeitsauslastungen von Anwendungen zu ermöglichen.
Sie können den Komprimierungsaufwand weiter optimieren, indem Sie die Komprimierungsstärke für das Erreichen des gewünschten Verhältnisses zwischen Komprimierung und CPU-Aufwand konfigurieren. Das ist jedoch noch nicht alles. Sie können Ihre Anwendung auch so konfigurieren, dass die Zwischenspeicherung der komprimierten Inhalte ermöglicht wird, wodurch der Komprimierungsaufwand für Cachetreffer entfällt, da bereits komprimierte Inhalte bereitgestellt werden. Beachten Sie, dass sowohl der ASP.NET- als auch der IIS-Ausgabecache mit der optionalen Funktion zum Zwischenspeichern komprimierter Inhalte für Clients, die dies unterstützen, sowie zum Verarbeiten von Anforderungen von Clients, die unkomprimierte Inhalte erfordern, aktualisiert wurden.
Einschränken der Medienbitrate
Aufgrund der zunehmenden Anzahl von Websites, auf denen Medieninhalte angeboten werden, schießen die Bandbreitenkosten für viele Unternehmen in die Höhe. Schlimmer ist noch, dass ein großer Prozentsatz der Medienbandbreite verschwendet wird, weil die an den Client gesendeten Medieninhalte nie wirklich verwendet werden. Warum?
Denken Sie an das letzte Mal, als Sie sich ein Onlinevideo angeschaut oder beim Surfen eine Videowerbung gesehen haben. Haben Sie sich das Video wirklich bis zum Ende angesehen? Häufig schauen sich Benutzer, die Videowebsites durchsuchen, nur einen Teil eines Videos an, bevor sie zum nächsten Video wechseln oder die Seite verlassen. Ein Webserver, bei dem zur Bereitstellung des Videos progressives Herunterladen verwendet wird, sendet jedoch in der Regel mehr Daten, als für diese Wiedergabezeit von wenigen Sekunden benötigt werden. Die meisten dieser Daten werden nie verwendet.
Wenn Ihre Videos im Durchschnitt nur 5 Sekunden lang angezeigt werden, in diesen 5 Sekunden jedoch Videodaten für 30 Sekunden bereitgestellt (gepuffert) werden, verschwenden Sie möglicherweise mehr als 80 Prozent Ihrer Bandbreite!
Vor einem Jahr entwickelte ich zur Lösung dieses Problems für einen Kunden, der eine Betaversion von IIS 7.0 einführte, ein Modul zur Bandbreiteneinschränkung, das die Videobitrate automatisch erkannte und sicherstellte, dass der Server das Video mit ungefähr derselben Rate an den Client sendete. Das IIS-Medienteam übernahm dieses Modul, das als „Bit Rate Throttling Module“ bezeichnet wird (siehe Abbildung 4) und im Download Center von iis.net (iis.net/downloads/?tabid=34&g=6&i=1640) verfügbar ist. Weitere Informationen dazu finden Sie im Blog von Scott Guthrie (unter go.microsoft.com/fwlink/?LinkId=122514 verfügbar).
Abbildung 4 Die Bitrateneinschränkung minimiert die Bandbreitenverwendung (zum Vergrößern auf das Bild klicken)
Das Bit Rate Throttling Module erkennt automatisch die Codierungsrate der gängigsten Videotypen. Sie können steuern, wie viele Daten Sie vorab an den Client senden möchten, um anfängliche Pufferungsverzögerungen zu beseitigen (Schnellstart), und mit welchem Prozentsatz der codierten Rate Sie die Inhalte bereitstellen möchten. Darüber hinaus können Sie viele weitere Optionen wie die maximale Bandbreite und die maximale Anzahl gleichzeitiger Verbindungen konfigurieren und das Modul durch ein Programm steuern.
Ausgabezwischenspeicherung
Im Allgemeinen ist die Zwischenspeicherung die beste Möglichkeit zur Verbesserung der Leistung von Anwendungen, die wiederholte Aufgaben ausführen. Im Gegensatz zu anwendungsspezifischen Leistungsverbesserungen, die häufig zahlreiche Anstrengungen erfordern und auf die Verringerung des Verarbeitungsaufwands einer Anwendung abzielen, entfällt durch die Zwischenspeicherung der Mehraufwand für wiederholte Anforderungen derselben Inhalte.
Vor IIS 7.0 boten sowohl IIS als auch ASP.NET Zwischenspeicherfunktionen in Form des IIS-Kernelcache und des ASP.NET-Ausgabecache. Der IIS-Kernelcache zeichnete sich durch maximale Leistung aus, war aber hauptsächlich auf statische Inhalte beschränkt. Der ASP.NET-Ausgabecache war eine weitaus umfassendere Lösung für die Zwischenspeicherung dynamischer Inhalte, wenn auch mit geringerer Leistung und weniger effizienter Speicherverwaltung. Der neue Ausgabecache in IIS 7.0 schließt die Lücke zwischen dem IIS-Kernelcache und dem ASP.NET-Ausgabecache.
Der Ausgabecache von IIS 7.0 ermöglicht das Zwischenspeichern dynamischer Inhalte aus beliebigen Anwendungen, einschließlich ASP, ASP.NET, PHP und jedes anderen mit IIS 7.0 kompatiblen Anwendungsframeworks. Durch die Bereitstellung grundlegender Unterstützung für die Variabilität und den Ablauf von Inhalten ermöglicht dieses neue Feature die Implementierung der Zwischenspeicherung für Inhalte, die vom IIS-Kernelcache nicht zwischengespeichert werden können. Gleichzeitig kann der Kernelcache nach wie vor für Inhalte verwendet werden, die den Einschränkungen entsprechen.
Darüber hinaus bietet der Ausgabecache von IIS 7.0 eine leistungsfähigere Alternative zum ASP.NET-Ausgabecache für ASP.NET-Inhalte, für die die erweiterten Zwischenspeicherfeatures (wie Cacheabhängigkeiten oder -invalidierung) nicht benötigt werden, die nur im ASP.NET-Ausgabecache verfügbar sind.
Im Hinblick auf die Ausgabezwischenspeicherung liegen die Herausforderungen normalerweise in der Definition angemessener Richtlinien für den Ablauf, die Invalidierung und die Variabilität von Inhalten, die das effiziente Zwischenspeichern von Antworten unter Aufrechterhaltung der erforderlichen Gültigkeit und Aktualität des Cache ermöglichen. In vielen Fällen können Sie dies einfach durch Konfiguration der richtigen Zwischenspeicherungsregeln erreichen, obwohl einige Situationen komplexere Richtlinien erfordern, die von Laufzeitinformationen abhängen. Der Ausgabecache von IIS 7.0 bietet hierfür programmgesteuerte APIs, die zur Gewährleistung des erforderlichen Zwischenspeicherungsverhaltens verwendet werden können. Dadurch wird das Leistungspotenzial der Zwischenspeicherung für Inhalte erschlossen, die andernfalls nicht von der Zwischenspeicherung profitieren würden. Darüber hinaus ermöglicht die integrierte ASP.NET-Pipeline die Verwendung des ASP.NET-Ausgabecache für andere Inhalte als ASP.NET-Inhalte.
Die Bereitstellung der Ausgabezwischenspeicherung für dynamische Inhalte kann schwierig sein und erfordert möglicherweise eine mehrstufige Strategie für die Nutzung der Effizienz und Flexibilität der verschiedenen Zwischenspeicherfeatures auf der IIS 7.0-Plattform. Hierzu gehört häufig das Beschreiben mehrerer Parameter, die sich auf die Antwort auswirken, und das Definieren von Ablauf- und Invalidierungsstrategien zur Aufrechterhaltung der Aktualität des Cache und die anschließende Feststellung, welcher Cache die erforderliche Semantik unterstützt.
Diese Komplexität lohnt sich jedoch fast immer. Durch Implementieren des Ausgabecache von IIS 7.0 können Sie beim Gesamtdurchsatz Ihrer Anwendung Verbesserungen um mehrere Größenordnungen und eine entsprechende Auslastungsverringerung bei Ihren Komponenten auf der Datenbank- und Geschäftsebene erreichen.
Konvertieren von ISAPI-Code in IIS 7.0-Module
Mit IIS 7.0 wird eine neue Server-API eingeführt, auf der alle IIS 7.0-Module basieren. Sie ersetzt die älteren ISAPI-Filter- und ISAPI-Erweiterungs-APIs, die in früheren Versionen von IIS verwendet wurden. Für neue Module, die frühere Versionen nicht unterstützen müssen, sind die neuen APIs einfacher zu verwenden, helfen bei der Erstellung von zuverlässigerem serverseitigem Code und sind viel leistungsfähiger.
IIS 7.0 bietet jedoch eine Option, mit der vorhandene ISAPI-Filter und -Erweiterungen durch eine über optionale IIS 7.0-Module implementierte Kompatibilitätsschicht unterstützt werden können. Dadurch können vorhandene ISAPI-Komponenten unter IIS 7.0 funktionieren, ohne dass sie neu geschrieben werden müssen.
Obwohl die Verwendung vorhandener ISAPI-Investitionen die Migration nach IIS 7.0 erleichtert, sollten Sie ausdrücklich in Betracht ziehen, den ISAPI-Legacycode auf die neuen IIS 7.0-APIs zu portieren. Dadurch erübrigt sich der Aufwand für die ISAPI-Kompatibilitätsschicht, und es ergeben sich Leistungsvorteile, die für ISAPI-Komponenten nicht verfügbar sind. Je nach der von der ISAPI-Komponente übernommenen Arbeit können diese Leistungsvorteile recht bedeutend sein. Die Modul-API von IIS 7.0 bietet beispielsweise integrierte Unterstützung für das Zwischenspeichern von Konfigurationsmetadaten und beliebigen anderen Daten, die mit Websites, Anwendungen und URLs verknüpft sind. Dadurch können die internen Vorgänge der Komponente deutlich beschleunigt werden.
Darüber hinaus ermöglicht die Modul-API von IIS Modulen die asynchrone Durchführung zeitintensiver Vorgänge wie das Empfangen von Anforderungseinheitsdaten oder das Senden der Antwort. Die asynchrone Durchführung dieser Aufgaben ermöglicht dem Server die Skalierung für eine sehr große Zahl gleichzeitiger Clients (im Zehntausenderbereich), statt bei mehreren tausend oder einigen hundert gleichzeitigen Clients aufgrund von Beschränkungen hinsichtlich der Anzahl von Anforderungsthreads das Maximum zu erreichen. Die asynchrone Verarbeitung kann auch die Auswirkung der Verarbeitung auf andere Anforderungen und Aktivitäten in der Anwendung beseitigen, die Speicherauslastung verringern und eine viel bessere CPU-Auslastung ermöglichen.
Zusätzlich zu den spezifischen leistungswirksamen Mustern bietet die systemeigene API Entwicklern größere Flexibilität für Anforderungsverarbeitungsaufgaben. Dadurch können Sie den Entwurf der Serverkomponente verbessern und wiederum eine hohe Effizienz ermöglichen. So können beispielsweise bestimmte Filterungsaufgaben, die zuvor ISAPI-Platzhaltererweiterungen und die Ausführung untergeordneter Anforderungen erforderten, jetzt während der ursprünglichen Anforderung in einem Modul durchgeführt werden. Dabei kann auch die Zwischenspeicherung im IIS-Kernelcache für die Antwort aktiviert werden.
Dies kann die Erstellung von Prototypen und einiges Experimentieren erfordern, um den optimalen Entwurf zu ermitteln, der die Vorteile der Migration maximiert. Aufgrund der grundlegenden Architekturunterschiede zwischen ISAPI und der Modul-API von IIS 7.0 ist die direkte Portierung nicht unbedingt der richtige Weg. Die gute Nachricht ist, dass die Modul-API von IIS 7.0 einfacher zu verwenden ist als ISAPI, wodurch sich die Migration weniger schwierig gestaltet.
Servererweiterbarkeit
IIS 7.0 bietet End-to-End-Erweiterbarkeit. Hierfür sind umfangreiche Vorkenntnisse hinsichtlich des Serverbetriebs erforderlich, gleichzeitig eröffnet sich jedoch auch ein enormes Potenzial für anwendungsspezifische Leistungsgewinne. Wenn Sie über ein gewisses Verständnis der Serverarchitektur und der Anforderungsverarbeitung verfügen, können Sie diese Erweiterbarkeit zum Entwurf benutzerdefinierter Leistungslösungen nutzen, die auf Ihre Anwendung, Arbeitsauslastung und Hardwareanforderungen zugeschnitten sind.
Hierzu können beliebige der integrierten IIS 7.0-Features durch benutzerdefinierte Implementierungen ersetzt werden. Obwohl die Features von IIS 7.0 einer umfangreichen Optimierung und Leistungsprüfung unterzogen wurden, wurden sie natürlich nicht für jeden möglichen Verwendungszweck optimiert. Daher können Sie die Leistung bestimmter Module möglicherweise durch die Integration von Optimierungen für Ihre spezifische Arbeitsauslastung verbessern. Sie könnten sich beispielsweise dafür entscheiden, das Verzeichnisauflistungsmodul wieder zu implementieren, um Verzeichnislisten im Arbeitsspeicher zwischenzuspeichern, statt Dateisystem-APIs zur Aufzählung von Dateien zu verwenden.
Alternativ kann die Erweiterbarkeit zur Erstellung neuer Leistungsfeatures verwendet werden. Zu den integrierten Beispielen für solche Features gehören der Ausgabecache, die Komprimierungsmodule und mehrere andere interne Caches.
Für die Feststellung, ob ein benutzerdefiniertes Leistungsfeature benötigt wird, müssen Sie die Leistungsmerkmale Ihrer Anwendung und ihre Arbeitsauslastung sowie die Engpässe kennen, die Sie beseitigen müssen. IIS 7.0 bietet umfangreiche Diagnoseunterstützung für die Leistungsanalyse, mit der sich die Anforderungen und der mögliche Entwurf der Features, die Sie benötigen, leichter erkennen lassen können.
Zusammenfassung
Obwohl es sich bei IIS 7.0 in erster Linie um eine funktionale Version handelt, bietet diese bemerkenswerte Leistungsverbesserungen, die auf ihrer modularen Architektur, Konfigurierbarkeit und neuen Leistungsfeatures beruhen. Diese Verbesserungen können durch Serverkonsolidierung und geringere Bandbreitenkosten den Weg für bedeutende geschäftliche Einsparungen ebnen sowie eine verbesserte Benutzerfreundlichkeit bieten.
Zur wirksamen Nutzung vieler dieser Verbesserungen ist es häufig notwendig, eine eingehende Analyse Ihrer aktuellen Anwendungsplattform durchzuführen und sich gründliche Kenntnisse in Bezug auf die Architektur von IIS 7.0 anzueignen. Weitere Informationen zur Architektur und zu den in diesem Artikel erwähnten Features von IIS 7.0 finden Sie unter „iis.net“. Zudem führe ich unter mvolo.com einen Blog zu Verfahren, bei denen IIS 7.0 proaktiv zur Verbesserung der Anwendungsleistung und zur Senkung der Betriebskosten genutzt wird.
Mike Volodarsky war früher Programmmanager im IIS-Team von Microsoft. In den letzten fünf Jahren arbeitete er an Entwurf und Entwicklung zentraler Features für ASP.NET 2.0 und IIS 7.0. Jetzt entwickelt er fortschrittliche Webservertechnologien für hochleistungsfähige Webfarmen mit IIS 7.0 und Windows Server 2008. Mike ist der Hauptautor des Buchs IIS 7.0 Resource Kit und verfasst Beiträge für das MSDN Magazin und seinen IIS 7.0-Blog unter mvolo.com.