Optimieren von IIS 10.0
Internetinformationsdienste (IIS) 10.0 ist in Windows Server 2022 enthalten. Es wird ein ähnliches Prozessmodell wie für IIS 8.5 und IIS 7.0 verwendet. Ein Kernelmodus-Webtreiber (HTTP.sys) empfängt HTTP-Anforderungen, leitet diese weiter und erfüllt Anforderungen aus seinem Antwortcache. Arbeitsprozesse werden für URL-Unterbereiche registriert, und HTTP.sys leitet die Anforderung an den entsprechenden Prozess (bzw. bei Anwendungspools an mehrere Prozesse) weiter.
HTTP.sys ist für die Verbindungsverwaltung und Anforderungsverarbeitung verantwortlich. Die Anforderung kann aus dem HTTP.sys-Cache bereitgestellt oder zur weiteren Verarbeitung an einen Arbeitsprozess übergeben werden. Es können mehrere Arbeitsprozesse konfiguriert werden, wodurch geringere Kosten für die Isolation ermöglicht werden. Weitere Informationen zur Funktionsweise der Anforderungsbehandlung finden Sie in der folgenden Abbildung:
HTTP.sys enthält einen Antwortcache. Wenn eine Anforderung mit einem Eintrag im Antwortcache übereinstimmt, sendet HTTP.sys die Cacheantwort direkt im Kernelmodus. Einige Webanwendungsplattformen, z. B. ASP.NET, verfügen über Mechanismen, mit denen dynamische Inhalte im Kernelmoduscache zwischengespeichert werden können. Der statische Dateihandler in IIS 10.0 speichert häufig angeforderte Dateien automatisch in HTTP.sys zwischen.
Da ein Webserver über Kernelmodus- und Benutzermoduskomponenten verfügt, müssen beide Komponenten optimiert werden, um eine optimale Leistung zu erreichen. Daher müssen zur Optimierung von IIS 10.0 für eine bestimmte Workload folgende Komponenten konfiguriert werden:
HTTP.sys und der zugehörigen Kernelmoduscache
Arbeitsprozesse und IIS im Benutzermodus, einschließlich Anwendungspoolkonfiguration
Bestimmte Optimierungsparameter, die sich auf die Leistung auswirken
In den folgenden Abschnitten wird erläutert, wie Sie die Kernelmodus- und Benutzermodusaspekte von IIS 10.0 konfigurieren.
Kernelmoduseinstellungen
Leistungsbezogene HTTP.sys-Einstellungen fallen in zwei allgemeine Kategorien: Cacheverwaltung sowie Verbindungs- und Anforderungsverwaltung. Alle Registrierungseinstellungen werden unter dem folgenden Registrierungseintrag gespeichert:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters
Hinweis Wenn der HTTP-Dienst bereits ausgeführt wird, müssen Sie ihn neu starten, damit die Änderungen wirksam werden.
Cacheverwaltungseinstellungen
Ein Vorteil, den HTTP.sys bietet, ist ein Kernelmoduscache. Wenn sich die Antwort im Kernelmoduscache befindet, können Sie eine HTTP-Anforderung vollständig im Kernelmodus erfüllen, wodurch die CPU-Kosten für die Verarbeitung der Anforderung erheblich gesenkt werden. Der Kernelmoduscache von IIS 10.0 basiert jedoch auf physischem Arbeitsspeicher. Die Kosten für einen Eintrag sind der belegte Arbeitsspeicher.
Ein Eintrag im Cache ist nur hilfreich, wenn er verwendet wird. Der Eintrag nimmt jedoch unabhängig davon, ob der Eintrag verwendet wird oder nicht, immer physischen Arbeitsspeicher in Anspruch. Sie müssen den Nutzen eines Elements im Cache (Einsparungen durch die mögliche Bereitstellung aus dem Cache) und seine Kosten (der belegte physische Arbeitsspeicher) für die Lebensdauer des Eintrags bewerten, indem Sie die verfügbaren Ressourcen (CPU und physischer Arbeitsspeicher) sowie die Workloadanforderungen berücksichtigen. HTTP.sys versucht, nur nützliche Elemente, auf die aktiv zugegriffen wird, im Cache zu behalten. Sie können die Leistung des Webservers jedoch erhöhen, indem Sie den HTTP.sys-Cache für bestimmte Workloads optimieren.
Nachstehend sind einige nützliche Einstellungen für den HTTP.sys-Kernelmoduscache aufgeführt:
UriEnableCache Standardwert: 1
Ein Wert ungleich Null aktiviert Antworten im Kernelmodus und die Zwischenspeicherung von Fragmenten. Für die meisten Workloads sollte der Cache aktiviert bleiben. Sie sollten den Cache deaktivieren, wenn sehr wenige Antworten und eine fragmentierte Zwischenspeicherung zu erwarten sind.
UriMaxCacheMegabyteCount Standardwert: 0
Ein Wert ungleich Null gibt den maximalen Arbeitsspeicher an, der für den Kernelmoduscache verfügbar ist. Der Standardwert 0 ermöglicht es dem System, den verfügbaren Arbeitsspeicher für den Cache automatisch anzupassen.
Hinweis Wenn Sie die Größe angeben, wird nur die maximale Größe festgelegt. Das System lässt möglicherweise aber nicht zu, dass der Cache auf die maximale festgelegte Größe anwächst.
Â
UriMaxUriBytes Standardwert: 262144 Bytes (256 KB)
Die maximale Größe eines Eintrags im Kernelmoduscache. Antworten oder Fragmente, die größer sind, werden nicht zwischengespeichert. Wenn Sie über genügend Arbeitsspeicher verfügen, sollten Sie erwägen, den Grenzwert zu erhöhen. Wenn der Arbeitsspeicher begrenzt ist und große Einträge kleinere Einträge verdrängen, kann es hilfreich sein, den Grenzwert zu senken.
UriScavengerPeriod Standardwert: 120 Sekunden
Der HTTP.sys-Cache wird regelmäßig von einem Aufräumprozess überprüft. Einträge, auf die zwischen Überprüfungen des Aufräumprozesses nicht zugegriffen wird, werden entfernt. Wenn Sie den Zeitraum für den Aufräumprozess auf einen hohen Wert festlegen, wird die Anzahl der Überprüfungen des Aufräumprozesses reduziert. Die Cachespeicherauslastung kann jedoch steigen, da ältere Einträge, auf die seltener zugegriffen wird, im Cache verbleiben können. Wenn Sie den Zeitraum zu niedrig festlegen, werden häufiger Überprüfungen des Aufräumprozesses durchgeführt, und dies kann zu übermäßig vielen Cacheleerungen und zu Cacheverlusten führen.
Einstellungen für die Anforderungs- und Verbindungsverwaltung
In Windows Server 2022 verwaltet HTTP.sys Verbindungen automatisch. Die folgenden Registrierungseinstellungen werden nicht mehr verwendet:
MaxConnections
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\MaxConnectionsIdleConnectionsHighMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsHighMarkIdleConnectionsLowMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsLowMarkIdleListTrimmerPeriod
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleListTrimmerPeriodRequestBufferLookasideDepth
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\RequestBufferLookasideDepthInternalRequestLookasideDepth
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\InternalRequestLookasideDepth
Benutzermoduseinstellungen
Die Einstellungen in diesem Abschnitt wirken sich auf das Verhalten der IIS 10.0-Arbeitsprozesse aus. Die meisten dieser Einstellungen finden Sie in der folgenden XML-Konfigurationsdatei:
%SystemRoot%\system32\inetsrv\config\applicationHost.config
Sie können diese mit Appcmd.exe, die IIS 10.0-Verwaltungskonsole, sowie mit den WebAdministration-bzw. IISAdministration-PowerShell-Cmdlets ändern. Die meisten Einstellungen werden automatisch erkannt, sodass kein Neustart der IIS 10.0-Arbeitsprozesse oder des Webanwendungsservers erforderlich ist. Weitere Informationen zur applicationHost.config-Datei finden Sie in der Einführung in ApplicationHost.config.
Ideale CPU-Einstellung für NUMA-Hardware
Ab Windows Server 2016 unterstützt IIS 10.0 die automatische ideale CPU-Zuweisung für seine Threadpoolthreads, um Leistung und Skalierbarkeit auf NUMA-Hardware zu verbessern. Dieses Feature ist standardmäßig aktiviert und kann über den folgenden Registrierungsschlüssel konfiguriert werden:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\ThreadPoolUseIdealCpu
Wenn dieses Feature aktiviert ist, unternimmt der IIS-Thread-Manager alles, um IIS-Threadpoolthreads basierend auf deren aktuellen Belastung gleichmäßig auf alle CPUs in allen NUMA-Knoten zu verteilen. Im Allgemeinen wird empfohlen, diese Standardeinstellung für NUMA-Hardware unverändert zu lassen.
Hinweis Die ideale CPU-Einstellung ist nicht mit den NUMA-Knotenzuweisungseinstellungen für Arbeitsprozesse (numaNodeAssignment und numaNodeAffinityMode) zu verwechseln, die in den CPU-Einstellungen für einen Anwendungspool eingeführt wurden. Die ideale CPU-Einstellung wirkt sich darauf aus, wie IIS seine Threadpoolthreads verteilt, während die NUMA-Knotenzuweisungseinstellungen für Arbeitsprozesse bestimmen, auf welchem NUMA-Knoten ein Arbeitsprozess gestartet wird.
Einstellungen für das Verhalten im Benutzermoduscache
In diesem Abschnitt werden die Einstellungen beschrieben, die sich auf das Cacheverhalten in IIS 10.0 auswirken. Der Benutzermoduscache ist als Modul implementiert, das auf die globalen Zwischenspeicherungsereignisse lauscht, die von der integrierten Pipeline ausgelöst werden. Um den Benutzermoduscache vollständig zu deaktivieren, entfernen Sie das Modul FileCacheModule (cachfile.dll) aus der Liste der installierten Module im Konfigurationsabschnitt „system.webServer/globalModules“ in „applicationHost.config“.
system.webServer/caching
| attribute | BESCHREIBUNG | Standard |
|---|---|---|
| Aktiviert | Deaktiviert den IIS-Benutzermoduscache bei Einstellung auf False. Wenn die Cachetrefferrate sehr gering ist, können Sie den Cache vollständig deaktivieren, um den Mehraufwand für den Cachecodepfad zu vermeiden. Wenn Sie den Benutzermoduscache deaktivieren, wird der Kernelmoduscache nicht deaktiviert. | True |
| enableKernelCache | Deaktiviert den Kernelmoduscache bei Einstellung auf False. | True |
| maxCacheSize | Beschränkt die Größe des IIS-Benutzermoduscache auf die angegebene Größe in Megabyte. IIS passt die Standardeinstellung abhängig vom verfügbaren Arbeitsspeicher an. Wählen Sie den Wert abhängig von der Größe der Dateien, auf die häufig zugegriffen wird, im Vergleich zur RAM-Größe oder dem IIS-Prozessadressraum sorgfältig aus. | 0 |
| maxResponseSize | Speichert Dateien bis zur angegebenen Größe zwischen. Der tatsächliche Wert hängt von der Anzahl und Größe der größten Dateien im Dataset im Vergleich zum verfügbaren RAM ab. Das Zwischenspeichern großer, häufig angeforderter Dateien kann die CPU-Auslastung, den Datenträgerzugriff und die jeweiligen Latenzzeiten verringern. | 262144 |
Einstellungen für das Komprimierungsverhalten
In IIS werden ab Version 7.0 statische Inhalte standardmäßig komprimiert. Außerdem ist die Komprimierung dynamischer Inhalte standardmäßig aktiviert, wenn DynamicCompressionModule installiert ist. Die Komprimierung reduziert die genutzte Bandbreite, erhöht jedoch die CPU-Auslastung. Komprimierte Inhalte werden nach Möglichkeit im Kernelmoduscache zwischengespeichert. Ab Version 8.5 ermöglicht IIS eine unabhängige Steuerung der Komprimierung für statische und dynamische Inhalte. Bei statischen Inhalt handelt es sich in der Regel um Inhalte, die sich nicht ändern, z. B. GIF- oder HTM-Dateien. Dynamische Inhalte werden in der Regel durch Skripts oder Code auf dem Server generiert (ASP.NET-Seiten). Sie können die Klassifizierung einer bestimmten Erweiterung als statisch oder dynamisch anpassen.
Um die Komprimierung vollständig zu deaktivieren, entfernen Sie StaticCompressionModule und DynamicCompressionModule aus der Liste der Module im Abschnitt „system.webServer/globalModules“ in „applicationHost.config“.
system.webServer/httpCompression
| attribute | BESCHREIBUNG | Standard |
|---|---|---|
| staticCompression-EnableCpuUsage staticCompression-DisableCpuUsage dynamicCompression-EnableCpuUsage dynamicCompression-DisableCpuUsage |
Aktiviert oder deaktiviert die Komprimierung, wenn die aktuelle CPU-Auslastung in Prozent die angegebenen Grenzwerte über- oder unterschreitet. Ab IIS 7.0 wird die Komprimierung automatisch deaktiviert, wenn die CPU-Auslastung dauerhaft über den Deaktivierungsschwellenwert steigt. Die Komprimierung wird aktiviert, wenn die CPU unter den Aktivierungsschwellenwert sinkt. |
50, 100, 50 bzw. 90 |
| directory | Gibt das Verzeichnis an, in dem komprimierte Versionen der statischen Dateien vorübergehend gespeichert und zwischengespeichert werden. Sie sollten dieses Verzeichnis vom Systemlaufwerk auf ein anderes Laufwerk verlagern, wenn häufig darauf zugegriffen wird. | %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files |
| doDiskSpaceLimiting | Gibt an, ob ein Grenzwert für den Speicherplatz vorhanden ist, den alle komprimierten Dateien belegen können. Komprimierte Dateien werden im Komprimierungsverzeichnis gespeichert, das durch das directory-Attribut angegeben wird. | True |
| maxDiskSpaceUsage | Gibt den Speicherplatz in Bytes an, den komprimierte Dateien im Komprimierungsverzeichnis belegen können. Diese Einstellung muss möglicherweise erhöht werden, wenn die Gesamtgröße aller komprimierten Inhalte zu umfangreich ist. |
100 MB |
system.webServer/urlCompression
| attribute | BESCHREIBUNG | Standard |
|---|---|---|
| doStaticCompression | Gibt an, ob statische Inhalte komprimiert werden. | True |
| doDynamicCompression | Gibt an, ob dynamische Inhalte komprimiert werden. | True |
Hinweis
Für Server mit IIS 10.0 mit geringer durchschnittlicher CPU-Auslastung sollten Sie die Komprimierung für dynamische Inhalte aktivieren, insbesondere bei umfangreichen Antworten. Dies sollte zuerst in einer Testumgebung erfolgen, um die Auswirkungen auf die CPU-Auslastung in Bezug auf die Baseline zu bewerten.
Optimieren der Standarddokumentliste
Das Standarddokumentmodul verarbeitet HTTP-Anforderungen für den Stamm eines Verzeichnisses und übersetzt diese in Anforderungen für eine bestimmte Datei, z. B. Default.htm oder Index.htm. Im Durchschnitt durchlaufen rund 25 Prozent aller Anforderungen im Internet den Standarddokumentpfad. Dieser Wert schwankt für einzelne Websites erheblich. Wenn eine HTTP-Anforderung keinen Dateinamen angibt, sucht das Standarddokumentmodul den jeweiligen Namen im Dateisystem in der Liste der zulässigen Standarddokumente. Dies kann sich negativ auf die Leistung auswirken, insbesondere wenn zum Erreichen des Inhalts ein Roundtrip im Netzwerk oder die Beanspruchung eines Datenträgers erforderlich ist.
Sie können den Mehraufwand vermeiden, indem Sie Standarddokumente selektiv deaktivieren und die Liste der Dokumente reduzieren oder sortieren. Bei Websites, die ein Standarddokument verwenden, sollten Sie die Liste auf die verwendeten Standarddokumenttypen reduzieren. Ordnen Sie die Liste außerdem so an, dass die Dateinamen der am häufigsten aufgerufenen Standarddokumente am Anfang stehen.
Sie können das Standarddokumentverhalten für bestimmte URLs selektiv festlegen, indem Sie die Konfiguration in einem location-Tag in applicationHost.config anpassen oder eine web.config-Datei direkt in das Inhaltsverzeichnis einfügen. Dies ermöglicht eine hybride Vorgehensweise, bei der Standarddokumente nur dort aktiviert werden, wo sie erforderlich sind, und die Liste für jede URL auf den richtigen Dateinamen festgelegt wird.
Um Standarddokumente vollständig zu deaktivieren, entfernen Sie DefaultDocumentModule aus der Liste der Module im Abschnitt „system.webServer/globalModules“ in „applicationHost.config“.
system.webServer/defaultDocument
| attribute | BESCHREIBUNG | Standard |
|---|---|---|
| enabled | Gibt an, dass Standarddokumente aktiviert sind. | True |
<files>-Element |
Gibt die Dateinamen an, die als Standarddokumente konfiguriert sind. | Die Standardliste umfasst Default.htm, Default.asp, Index.htm, Index.html, Iisstart.htm und Default.aspx. |
Zentralisierte binäre Protokollierung
Wenn die Serversitzung über zahlreiche untergeordnete URL-Gruppen verfügt, kann das Erstellen von Hunderten von formatierten Protokolldateien für einzelne URL-Gruppen und das Schreiben der Protokolldaten auf einen Datenträger schnell wertvolle CPU- und Arbeitsspeicherressourcen verbrauchen, sodass Leistungs- und Skalierbarkeitsprobleme entstehen. Die zentralisierte binäre Protokollierung minimiert den Umfang der Systemressourcen, die für die Protokollierung verwendet werden, und stellt gleichzeitig detaillierte Protokolldaten für Organisationen bereit, die diese benötigen. Für die Analyse von Protokollen im Binärformat ist ein Nachbearbeitungstool erforderlich.
Sie können die zentralisierte binäre Protokollierung aktivieren, indem Sie das centralLogFileMode-Attribut auf CentralBinary und das enabled-Attribut auf True festlegen. Sie sollten den Speicherort der zentralen Protokolldatei von der Systempartition auf ein dediziertes Protokollierungslaufwerk verlagern, um Konflikte zwischen Systemaktivitäten und Protokollierungsaktivitäten zu vermeiden.
system.applicationHost/log
| attribute | BESCHREIBUNG | Standard |
|---|---|---|
| centralLogFileMode | Gibt den Protokollierungsmodus für einen Server an. Ändern Sie diesen Wert in CentralBinary, um die zentralisierte binäre Protokollierung zu aktivieren. | Website |
system.applicationHost/log/centralBinaryLogFile
| attribute | BESCHREIBUNG | Standard |
|---|---|---|
| enabled | Gibt an, ob die zentrale binäre Protokollierung aktiviert ist. | False |
| directory | Gibt das Verzeichnis an, in das Protokolleinträge geschrieben werden. | %SystemDrive%\inetpub\logs\LogFiles |
Anwendungs- und Websiteoptimierungen
Die folgenden Einstellungen beziehen sich auf Anwendungspool- und Websiteoptimierungen.
system.applicationHost/applicationPools/applicationPoolDefaults
| attribute | BESCHREIBUNG | Standard |
|---|---|---|
| queueLength | Teilt HTTP.sys mit, wie viele Anforderungen für einen Anwendungspool in die Warteschlange gestellt werden, bevor zukünftige Anforderungen abgelehnt werden. Wenn der Wert für diese Eigenschaft überschritten wird, lehnt IIS nachfolgende Anforderungen mit dem Fehler 503 ab. Sie sollten diesen Wert für Anwendungen erhöhen, die mit Back-End-Datenspeichern mit hoher Latenz kommunizieren, wenn 503-Fehler auftreten. |
1000 |
| enable32BitAppOnWin64 | Aktiviert bei Einstellung auf „True“ die Ausführung einer 32-Bit-Anwendung auf einem Computer mit einem 64-Bit-Prozessor. Sie sollten den 32-Bit-Modus aktivieren, wenn der Arbeitsspeicherverbrauch ein Problem darstellt. Da die Größe von Zeigern und Anweisungen kleiner sind, verbrauchen 32-Bit-Anwendungen weniger Arbeitsspeicher als 64-Bit-Anwendungen. Der Nachteil der Ausführung von 32-Bit-Anwendungen auf einem 64-Bit-Computer besteht darin, dass der Adressraum im Benutzermodus auf 4 GB beschränkt ist. |
False |
system.applicationHost/sites/VirtualDirectoryDefault
| attribute | BESCHREIBUNG | Standard |
|---|---|---|
| allowSubDirConfig | Gibt an, ob IIS in Inhaltsverzeichnissen, die sich unterhalb der aktuelle Ebene befinden, nach web.config-Dateien sucht (True) oder nicht (False). Durch eine einfache Einschränkung, die eine Konfiguration nur in virtuellen Verzeichnissen zulässt, weiß IIS 10.0, dass nicht nach einer Konfigurationsdatei gesucht werden soll, außer wenn /<name>.htm ein virtuelles Verzeichnis ist. Durch Überspringen der zusätzlichen Dateivorgänge kann die Leistung von Websites, die über eine sehr große Anzahl von wahlfrei abgerufenen statischen Inhalten verfügen, erheblich verbessert werden. | True |
Verwalten von IIS 10.0-Modulen
IIS 10.0 wurde in mehrere, vom Benutzer erweiterbare Module zerlegt, um eine modulare Struktur zu unterstützen. Mit dieser Zerlegung sind geringe Kosten verbunden. Für jedes Modul muss die integrierte Pipeline das Modul für jedes Ereignis aufrufen, das für das Modul von Bedeutung ist. Dies geschieht unabhängig davon, ob das Modul eine Verarbeitung durchführen muss. Sie können CPU-Zyklen und Arbeitsspeicher sparen, indem Sie alle Module entfernen, die für eine bestimmte Website nicht relevant sind.
Ein Webserver, der für einfache statische Dateien optimiert ist, muss möglicherweise nur die folgenden fünf Module enthalten: UriCacheModule, HttpCacheModule, StaticFileModule, AnonymousAuthenticationModule und HttpLoggingModule.
Um Module aus „applicationHost.config“ zu entfernen, entfernen Sie alle Verweise auf das Modul aus den Abschnitten „system.webServer/handlers“ und „system.webServer/modules“ sowie die Moduldeklaration in „system.webServer/globalModules“.
Klassische ASP-Einstellungen
Die Hauptkosten für die Verarbeitung einer klassischen ASP-Anforderung umfassen das Initialisieren einer Skriptmodul, das Kompilieren des angeforderten ASP-Skripts in eine ASP-Vorlage und das Ausführen der Vorlage im Skriptmodul. Während die Kosten für die Vorlagenausführung von der Komplexität des angeforderten ASP-Skripts abhängen, kann das klassische ASP-Modul von IIS Skriptmodule im Arbeitsspeicher sowie Vorlagen sowohl im Arbeitsspeicher als auch auf dem Datenträger (nur wenn der In-Memory-Cache für Vorlagen nicht mehr ausreicht) zwischenspeichern, um die Leistung in CPU-gebundenen Szenarien zu steigern.
Die folgenden Einstellungen werden zum Konfigurieren des klassischen ASP-Vorlagencaches und des Skriptmodulcaches verwendet und wirken sich nicht auf ASP.NET-Einstellungen aus.
system.webServer/asp/cache
| attribute | BESCHREIBUNG | Standard |
|---|---|---|
| diskTemplateCacheDirectory | Der Name des Verzeichnisses, das ASP zum Speichern kompilierter Vorlagen verwendet, wenn der In-Memory-Cache überläuft. Empfehlung: Verwenden Sie ein Verzeichnis, das wenig genutzt wird, z. B. ein Laufwerk, das nicht für Betriebssystem, IIS-Protokoll oder andere häufig verwendete Inhalte genutzt wird. |
%SystemDrive%\inetpub\temp\ASP Compiled Templates |
| maxDiskTemplateCacheFiles | Gibt die maximale Anzahl kompilierter ASP-Vorlagen an, die auf dem Datenträger zwischengespeichert werden können. Empfehlung: Legen Sie diese Einstellung auf den maximalen Wert von 0x7FFFFFFF fest. |
2000 |
| scriptFileCacheSize | Dieses Attribut gibt die maximale Anzahl kompilierter ASP-Vorlagen an, die im Arbeitsspeicher zwischengespeichert werden können. Empfehlung: Legen Sie diese Einstellung mindestens auf die Anzahl häufig angeforderter ASP-Skripts fest, die von einem Anwendungspool verarbeitet werden. Legen Sie diese Einstellung nach Möglichkeit auf so viele ASP-Vorlagen fest, wie die Arbeitsspeichergrenzen zulassen. |
500 |
| scriptEngineCacheMax | Gibt die maximale Anzahl von Skriptmodulen an, die im Arbeitsspeicher zwischengespeichert werden. Empfehlung: Legen Sie diese Einstellung mindestens auf die Anzahl häufig angeforderter ASP-Skripts fest, die von einem Anwendungspool verarbeitet werden. Legen Sie diese Einstellung nach Möglichkeit auf so viele Skriptmodule fest, wie die Arbeitsspeichergrenzen zulassen. |
250 |
system.webServer/asp/limits
| attribute | BESCHREIBUNG | Standard |
|---|---|---|
| processorThreadMax | Gibt die maximale Anzahl von Arbeitsthreads pro Prozessor an, die ASP erstellen kann. Erhöhen Sie den Wert, wenn die aktuelle Einstellung nicht ausreicht, um die Last zu verarbeiten, was Fehler bei der Verarbeitung von Anforderungen verursachen kann, oder eine Unterauslastung der CPU-Ressourcen besteht. | 25 |
system.webServer/asp/comPlus
| attribute | BESCHREIBUNG | Standard |
|---|---|---|
| executeInMta | Legen Sie diese Einstellung auf True fest, wenn Fehler erkannt werden, während IIS ASP-Inhalte verarbeitet. Dies kann beispielsweise passieren, wenn mehrere isolierte Websites gehostet werden und jede Website in einem eigenen Arbeitsprozess ausgeführt wird. Fehler werden in der Regel von COM+ in der Ereignisanzeige gemeldet. Diese Einstellung aktiviert das Multithread-Apartmentmodell in ASP. | False |
ASP.NET-Parallelitätseinstellung
ASP.NET 3.5
Standardmäßig schränkt ASP.NET die Parallelität von Anforderungen ein, um den stationären Arbeitsspeicherverbrauch auf dem Server zu reduzieren. Für Anwendungen mit hoher Parallelität müssen möglicherweise einige Einstellungen angepasst werden, um die Gesamtleistung zu verbessern. Sie können diese Einstellung in der aspnet.config-Datei ändern:
<system.web>
<applicationPool maxConcurrentRequestsPerCPU="5000"/>
</system.web>
Die folgende Einstellung ist nützlich, um Ressourcen in einem System vollständig zu nutzen:
maxConcurrentRequestPerCpu Standardwert: 5000
Diese Einstellung begrenzt die maximale Anzahl gleichzeitig ausgeführter ASP.NET-Anforderungen in einem System. Der Standardwert ist konservativer Wert, um den Arbeitsspeicherverbrauch von ASP.NET-Anwendungen zu reduzieren. Sie sollten diesen Grenzwert für Systeme mit Anwendungen, die langwierige, synchrone E/A-Vorgänge ausführen, erhöhen. Andernfalls kann es aufgrund von Warteschlangen- oder Anforderungsfehlern wegen Überschreitung der Warteschlangengrenzwerte bei hoher Last zu langen Wartezeiten für Benutzer kommen, wenn die Standardeinstellung verwendet wird.
ASP.NET 4.6
Neben der Einstellung maxConcurrentRequestPerCpu bietet ASP.NET 4.7 auch Einstellungen zur Verbesserung der Leistung in Anwendungen, die stark von asynchronen Vorgängen abhängig sind. Die Einstellung kann in der aspnet.config-Datei geändert werden.
<system.web>
<applicationPool percentCpuLimit="90" percentCpuLimitMinActiveRequestPerCpu="100"/>
</system.web>
- percentCpuLimit Standardwert: 90. Die asynchrone Anforderung weist einige Skalierbarkeitsprobleme auf, wenn ein solches Szenario (über die Hardwaremöglichkeiten hinaus) übermäßig belastet wird. Das Problem entsteht durch die Art der Zuteilung in asynchronen Szenarien. Unter diesen Bedingungen erfolgt die Zuteilung, wenn der asynchrone Vorgang gestartet wird, und sie wird in Anspruch genommen, wenn der Vorgang durchgeführt wird. Zu diesem Zeitpunkt ist es gut möglich, dass die Objekte vom GC in Generation 1 oder 2 verschoben wurden. In diesem Fall steigt die Anzahl der Anforderungen pro Sekunde (rps) bis zu einem bestimmten Punkt an, wenn die Last zunimmt. Sobald dieser Punkt überschritten wird, wird die in GC verbrachte Zeit zu einem Problem, sodass die Anforderungen pro Sekunde wieder sinken, was sich negativ auf die Skalierung auswirkt. Wenn die CPU-Auslastung die Einstellung percentCpuLimit-Einstellung überschreitet, werden Anforderungen an die native ASP.NET-Warteschlange gesendet, um das Problem zu beheben.
- percentCpuLimitMinActiveRequestPerCpu Standardwert: 100. Die CPU-Drosselung (percentCpuLimit-Einstellung) hängt nicht von der Anzahl der Anforderungen, sondern von deren Kosten ab. Daher kann es nur wenige CPU-intensive Anforderungen geben, die in der nativen Warteschlange ohne Möglichkeit, diese abgesehen von eingehenden Anforderungen zu leeren, gesichert werden. Um dieses Problem zu lösen, kann percentCpuLimitMinActiveRequestPerCpu verwendet werden, um sicherzustellen, dass eine minimale Anzahl von Anforderungen verarbeitet wird, bevor die Drosselung einsetzt.
Arbeitsprozess- und Wiederverwendungsoptionen
Sie können Optionen für die Wiederverwendung von IIS-Workerprozessen konfigurieren und praktische Lösungen für akute Situationen oder Ereignisse bereitstellen, ohne dass ein Eingreifen erforderlich ist bzw. ein Dienst oder Computer zurückgesetzt werden muss. Zu diesen Situationen und Ereignissen gehören Speicherverluste, die Erhöhung der Arbeitsspeicherauslastung bzw. nicht reagierende oder im Leerlauf befindliche Arbeitsprozesse. Unter normalen Bedingungen werden Wiederverwendungsoptionen möglicherweise nicht benötigt, sodass die Wiederverwendung deaktiviert werden kann, oder das System kann so konfiguriert werden, dass sehr selten eine Wiederverwendung erfolgt.
Sie können das Prozesswiederverwendung für eine bestimmte Anwendung aktivieren, indem Sie zum recycling/periodicRestart-Element Attribute hinzufügen. Das Wiederverwendungsereignis kann durch mehrere Ereignisse ausgelöst werden, z. B. Arbeitsspeicherauslastung, eine feste Anzahl von Anforderungen und einen festen Zeitraum. Wenn ein Arbeitsprozess wiederverwendet wird, werden die in die Warteschlange eingereihten und ausführenden Anforderungen gelöscht. Gleichzeitig wird ein neuer Prozess gestartet, um neue Anforderungen zu verarbeiten. Das Recycling/periodicRestart-Element gilt jeweils für eine Anwendung. Dies bedeutet, dass jedes Attribut in der folgenden Tabelle auf Anwendungsbasis partitioniert wird.
system.applicationHost/applicationPools/ApplicationPoolDefaults/recycling/periodicRestart
| attribute | BESCHREIBUNG | Standard |
|---|---|---|
| Arbeitsspeicher | Aktiviert die Prozesswiederverwendung, wenn der virtuelle Arbeitsspeicherverbrauch den angegebenen Grenzwert in Kilobyte überschreitet. Dies ist eine nützliche Einstellung für 32-Bit-Computer mit einem kleinen Adressraum von 2 GB. Dies kann dazu beitragen, fehlgeschlagene Anforderungen durch Fehler zu vermeiden, weil nicht genügend Arbeitsspeicher vorhanden ist. | 0 |
| privateMemory | Aktiviert die Prozesswiederverwendung, wenn private Arbeitsspeicherzuteilungen einen angegebenen Grenzwert in Kilobyte überschreiten. | 0 |
| requests | Aktiviert die Prozesswiederverwendung nach einer bestimmten Anzahl von Anforderungen. | 0 |
| time | Aktiviert die Prozesswiederverwendung nach einem bestimmten Zeitraum. | 29:00:00 |
Optimierung der dynamischen Auslagerung von Arbeitsprozessen
Ab Windows Server 2012 R2 bietet IIS die Möglichkeit, den Arbeitsprozess so zu konfigurieren, dass er angehalten wird, nachdem er für eine Weile im Leerlauf war (zusätzlich zur Option zum Beenden, die seit IIS 7 besteht).
Der Hauptzweck der Auslagerung eines Arbeitsprozesses im Leerlauf sowie der Beendigung des Arbeitsprozesses im Leerlauf besteht darin, den Arbeitsspeicher auf dem Server sparsam zu nutzen, da eine Website auch dann viel Arbeitsspeicher verbrauchen kann, wenn er inaktiv und lediglich lauscht. Abhängig von der Technologie, die von der Website verwendet wird (statischer Inhalt, ASP.NET, andere Frameworks), kann der genutzte Arbeitsspeicher zwischen etwa 10 MB und Hunderten von MB liegen. Wenn Ihr Server mit vielen Websites konfiguriert ist, kann die Ermittlung der effektivsten Einstellungen für die Websites die Leistung von aktiven und angehaltenen Websites erheblich verbessern.
Bevor wir auf Einzelheiten eingehen, müssen wir bedenken, dass es wahrscheinlich am besten ist, die Websites so einzurichten, dass sie niemals angehalten oder beendet werden. Es ergibt nämlich wenig Sinn, einen Worker-Prozess zu beenden, wenn er der einzige auf dem Computer ist.
Hinweis
Falls auf der Website instabiler Code ausgeführt wird, z. B. Code mit einem Speicherverlust oder anderweitig instabiler Code, kann das Beenden der Website im Leerlauf eine Quick-and-Dirty-Alternative zur Behebung des Codefehlers sein. Dies ist zwar nicht empfehlenswert, es kann aber in einer kritischen Situation besser sein, dieses Feature als Bereinigungsmechanismus zu verwenden, während eine beständig Lösung in Arbeit ist.
Ein weiterer zu berücksichtigender Faktor ist, dass der Auslagerungsprozess selbst bei einer umfangreichen Arbeitsspeicherauslastung durch eine Website mit Kosten verbunden ist, da der Computer die vom Arbeitsprozess verwendeten Daten auf den Datenträger schreiben muss. Wenn der Arbeitsprozess einen großen Arbeitsspeicherblock verwendet, kann das Anhalten teurer sein als die Kosten, die durch die Verzögerung entstehen, bis er wieder gestartet wird.
Um das Feature zum Anhalten des Arbeitsprozesses optimal zu nutzen, müssen Sie Ihre Websites in jedem Anwendungspool überprüfen und entscheiden, welche angehalten bzw. beendet werden sollen und welche immer aktiv sein sollen. Für jede Aktion und jede Website müssen Sie den idealen Timeoutzeitraum ermitteln.
Im Idealfall sind die Websites, die Sie zum Anhalten oder Beenden konfigurieren, Websites, die zwar jeden Tag besucht werden, aber nicht so häufig, dass sie ständig aktiv bleiben müssen. Dies sind in der Regel Websites mit etwa 20 Besuchern pro Tag oder weniger. Sie können die Datenverkehrsmuster anhand der Protokolldateien der Website analysieren und den durchschnittlichen täglichen Datenverkehr berechnen.
Denken Sie daran, dass ein bestimmter Benutzer, sobald eine Verbindung mit der Website hergestellt wurde, in der Regel zumindest eine Weile auf der Website bleibt und zusätzliche Anforderungen stellt, sodass das Zählen der täglichen Anforderungen möglicherweise die tatsächlichen Datenverkehrsmuster nicht genau widerspiegelt. Um genauere Ergebnisse zu erhalten, können Sie auch ein Tool wie Microsoft Excel verwenden, um die durchschnittliche Zeit zwischen Anforderungen zu berechnen. Beispiel:
| Number | Anforderungs-URL | Anforderungszeit | Delta |
|---|---|---|---|
| 1 | /SourceSilverLight/Geosource.web/grosource.html | 10:01 | |
| 2 | /SourceSilverLight/Geosource.web/sliverlight.js | 10:10 Uhr | 0:09 |
| 3 | /SourceSilverLight/Geosource.web/clientbin/geo/1.aspx | 10:11 | 0:01 |
| 4 | /lClientAccessPolicy.xml | 10:12 | 0:01 |
| 5 | / SourceSilverLight/GeosourcewebService/Service.asmx | 10:23 | 0:11 |
| 6 | /SourceSilverLight/Geosource.web/GeoSearchServer...¦. | 11:50 | 1:27 |
| 7 | /rest/Services/CachedServices/Silverlight_load_la...¦ | 12:50 | 1:00 |
| 8 | /rest/Services/CachedServices/Silverlight_basemap...¦. | 12:51 | 0:01 |
| 9 | /rest/Services/DynamicService/ Silverlight_basemap...¦. | 12:59 | 0:08 |
| 10 | /rest/Services/CachedServices/Ortho_2004_cache.as... | 13:40 | 0:41 |
| 11 | /rest/Services/CachedServices/Ortho_2005_cache.js | 13:40 | 0:00 |
| 12 | /rest/Services/CachedServices/OrthoBaseEngine.aspx | 13:41 | 0:01 |
Der schwierige Teil besteht jedoch darin, herauszufinden, welche Einstellung sinnvoll ist. In unserem Fall erhält die Website eine Reihe von Anforderungen von Benutzern. Die obige Tabelle zeigt, dass insgesamt 4 eindeutige Sitzungen in einem Zeitraum von 4 Stunden stattgefunden haben. Mit den Standardeinstellungen des Anwendungspools für das Anhalten des Arbeitsprozesses würde die Website nach dem Standardtimeout von 20 Minuten beendet, sodass die Website für jeden dieser Benutzer wieder reaktiviert werden müsste. Dies macht die Website zu einem idealen Kandidaten für das Anhalten des Arbeitsprozesses, da sich die Website in den meisten Fällen im Leerlauf befindet, sodass das Anhalten Ressourcen sparen würde, aber Benutzer die Website fast sofort erreichen können.
Ein letzter und sehr wichtiger Hinweis ist, dass die Datenträgerleistung für dieses Feature von entscheidender Bedeutung ist. Da beim Anhalten und Reaktivieren große Datenmengen auf die Festplatte geschrieben und gelesen werden, wird dringend empfohlen, hierfür eine schnelle Festplatte zu verwenden. Solid State Drives (SSDs) sind dafür ideal und dringend zu empfehlen. Sie sollten außerdem sicherstellen, dass die Windows-Auslagerungsdatei darauf gespeichert wird. (Falls das Betriebssystem selbst nicht auf der SSD installiert ist, konfigurieren Sie das Betriebssystem so, dass die Auslagerungsdatei dorthin verschoben wird.)
Unabhängig davon, ob Sie eine SSD verwenden oder nicht, wird auch empfohlen, eine feste Größe der Auslagerungsdatei festzulegen, um das Schreiben der ausgelagerten Daten zu ermöglichen, ohne die Größe der Datei ändern zu müssen. Die Größe der Auslagerungsdatei kann geändert werden, wenn das Betriebssystem Daten in der Auslagerungsdatei speichern muss, da Windows standardmäßig so konfiguriert ist, dass die Größe automatisch je nach Bedarf angepasst wird. Wenn Sie die Größe auf eine bestimmte Größe festlegen, können Sie die Größenänderung verhindern und die Leistung erheblich verbessern.
Zum Konfigurieren einer festen Auslagerungsdateigröße müssen Sie die ideale Größe berechnen. Diese hängt davon ab, wie viele Websites Sie anhalten und wie viel Arbeitsspeicher diese verbrauchen. Wenn für einen aktiven Workerprozess durchschnittlich 200 MB benötigt werden und Sie über 500 Websites auf den Servern verfügen, die angehalten werden, sollte die Auslagerungsdatei mindestens (200 * 500) MB über der Basisgröße der Auslagerungsdatei liegen (in diesem Beispiel Basisgröße + 100 GB).
Hinweis
Wenn Websites angehalten werden, verbrauchen sie jeweils etwa 6 MB, sodass in diesem Fall die Arbeitsspeicherauslastung etwa 3 GB beträgt, wenn alle Websites angehalten werden. In der Realität werden Sie aber wahrscheinlich nie alle gleichzeitig sperren lassen können.
TLS-Optimierungsparameter
Die Verwendung von Transport Layer Security (TLS) verursacht zusätzliche CPU-Kosten. Die teuerste Komponente von TLS sind die Kosten für die Einrichtung einer Sitzung, da dabei ein vollständiger Handshake stattfindet. Die Wiederverbindung, Verschlüsselung und Entschlüsselung erhöhen ebenfalls die Kosten. Gehen Sie wie folgt vor, um eine bessere TLS-Leistung zu erzielen:
Aktivieren Sie HTTP-Keep-Alives für TLS-Sitzungen. Dadurch entfallen die Kosten für die Sitzungseinrichtung.
Verwenden Sie Sitzungen gegebenenfalls wieder, insbesondere bei Nicht-Keep-Alive-Datenverkehr.
Wenden Sie die Verschlüsselung selektiv nur auf Seiten oder Teile der Website an, für die dies erforderlich ist, und nicht auf die gesamte Website.
Hinweis
- Längere Schlüssel bieten mehr Sicherheit, verbrauchen aber auch mehr CPU-Zeit.
- Möglicherweise müssen nicht alle Komponenten verschlüsselt werden. Das Mischen von unverschlüsseltem HTTP und HTTPS kann jedoch zu einer Popupwarnung mit dem Hinweis führen, dass nicht alle Inhalte auf der Seite sicher sind.
Internet Server Application Programming Interface (ISAPI)
Für ISAPI-Anwendungen sind keine speziellen Optimierungsparameter erforderlich. Achten Sie beim Schreiben einer privaten ISAPI-Erweiterung darauf, dass Leistungs- und Ressourcennutzungsaspekte berücksichtigt werden.
Richtlinien zur Optimierung verwalteten Codes
Das integrierte Pipelinemodell in IIS 10.0 ermöglicht ein hohes Maß an Flexibilität und Erweiterbarkeit. Benutzerdefinierte Module, die in nativem oder verwaltetem Code implementiert sind, können in die Pipeline eingefügt werden oder vorhandene Module ersetzen. Obwohl dieses Erweiterbarkeitsmodell praktisch und einfach ist, sollten Sie vorsichtig sein, wenn Sie neue verwaltete Module einfügen, die in globale Ereignisse eingreifen. Das Hinzufügen eines global verwalteten Moduls bedeutet, dass alle Anforderungen, einschließlich statischer Dateianforderungen, verwalteten Code verwenden müssen. Benutzerdefinierte Module sind anfällig für Ereignisse wie Garbage Collection. Darüber hinaus führen benutzerdefinierte Module durch Marshallen von Daten zwischen nativem und verwaltetem Code zu erheblichen CPU-Kosten. Wenn möglich, sollten Sie preCondition für das verwaltete Modul auf managedHandler festlegen.
Um eine bessere Kaltstartleistung zu erzielen, sollten Sie die ASP.NET-Website unbedingt vorkompilieren oder die IIS-Anwendungsinitialisierungsfunktion verwenden, um die Anwendung aufzuwärmen.
Wenn der Sitzungszustand nicht benötigt wird, sollten Sie ihn unbedingt für die einzelnen Seiten deaktivieren.
Wenn es viele E/A-gebundene Vorgänge gibt, sollten Sie nach Möglichkeit die asynchrone Version der relevanten APIs verwenden, da dies eine viel bessere Skalierbarkeit ermöglicht.
Die korrekte Verwendung des Ausgabecaches erhöht ebenfalls die Leistung Ihrer Website.
Überwachen Sie die Speicherauslastung, wenn Sie mehrere Hosts ausführen, die ASP.NET Skripts im isolierten Modus enthalten (ein Anwendungspool pro Website). Stellen Sie sicher, dass der Server über genügend RAM für die erwartete Anzahl gleichzeitig ausgeführter Anwendungspools verfügt. Erwägen Sie die Verwendung mehrerer Anwendungsdomänen anstelle mehrerer isolierter Prozesse.
Andere Aspekte, die sich auf die IIS-Leistung auswirken
Die folgenden Aspekte können sich auf die IIS-Leistung auswirken:
Installation von Filtern, die nicht cachefähig sind
Die Installation eines Filters, der nicht HTTP-cachefähig ist, bewirkt, dass IIS die Zwischenspeicherung vollständig deaktiviert, was die Leistung beeinträchtigt. ISAPI-Filter, die vor IIS 6.0 geschrieben wurden, können dieses Verhalten verursachen.
CGI-Anforderungen
Aus Leistungsgründen wird die Verwendung von CGI-Anwendungen (Common Gateway Interface) zum Verarbeiten von Anforderungen mit IIS nicht empfohlen. Das Erstellen und Löschen von CGI-Prozessen ist häufig mit erheblichem Aufwand verbunden. Bessere Alternativen sind die Verwendung von FastCGI, ISAPI-Anwendungsskripts und ASP- oder ASP.NET-Skripts. Eine Isolation ist für jede dieser Optionen verfügbar.