Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Internetinformationsdienste (IIS) 10.0 ist in Windows Server 2022 enthalten. Es wird ein Prozessmodell verwendet, das dem von IIS 8.5 und IIS 7.0 ähnelt. Ein Kernelmodus-Webtreiber (http.sys) empfängt und leitet HTTP-Anforderungen weiter und erfüllt Anforderungen aus seinem Antwortcache. Arbeitsprozesse registrieren sich für URL-Unterbereiche, und http.sys leitet die Anforderung an den entsprechenden Prozess (oder eine Gruppe von Prozessen für Anwendungspools) weiter.
HTTP.sys ist für die Verbindungsverwaltung und die Bearbeitung von Anfragen verantwortlich. Die Anforderung kann aus dem HTTP.sys Cache verarbeitet oder zur weiteren Verarbeitung an einen Arbeitsprozess übergeben werden. Es können mehrere Arbeitsprozesse konfiguriert werden, was eine Isolation zu reduzierten Kosten ermöglicht. Weitere Informationen zur Funktionsweise der Anforderungsverarbeitung 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 aus dem Kernelmodus. Einige Webanwendungsplattformen, wie z. B. ASP.NET, bieten Mechanismen, mit denen dynamischer Inhalt im Kernelmoduscache zwischengespeichert werden kann. Der Handler für statische Dateien in IIS 10.0 speichert häufig angeforderte Dateien automatisch in http.syszwischen.
Da ein Webserver über Komponenten im Kernelmodus und im Benutzermodus verfügt, müssen beide Komponenten für eine optimale Leistung optimiert werden. Daher umfasst die Optimierung von IIS 10.0 für eine bestimmte Arbeitsauslastung die Konfiguration der folgenden Punkte:
HTTP.sys und der zugehörige Kernelmoduscache
Arbeitsprozesse und IIS im Benutzermodus, einschließlich der Konfiguration des Anwendungspools
Bestimmte Optimierungsparameter, die sich auf die Leistung auswirken
In den folgenden Abschnitten wird erläutert, wie Sie die Aspekte des Kernelmodus und des Benutzermodus von IIS 10.0 konfigurieren.
Einstellungen für den Kernelmodus
Leistungsbezogene HTTP.sys Einstellungen lassen sich in zwei große Kategorien einteilen: Cacheverwaltung und Verbindungs- und Anforderungsverwaltung. Alle Registrierungseinstellungen werden unter dem folgenden Registrierungseintrag gespeichert:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters
Anmerkung Wenn der HTTP-Dienst bereits ausgeführt wird, müssen Sie ihn neu starten, damit die Änderungen wirksam werden.
Einstellungen für die Cache-Verwaltung
Ein Vorteil, den HTTP.sys bietet, ist ein Cache im Kernelmodus. Wenn sich die Antwort im Kernelmoduscache befindet, können Sie eine HTTP-Anforderung vollständig aus dem 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, und die Kosten für einen Eintrag sind der Arbeitsspeicher, der belegt wird.
Ein Eintrag im Cache ist nur dann hilfreich, wenn er verwendet wird. Der Eintrag verbraucht jedoch immer physischen Speicher, unabhängig davon, ob der Eintrag verwendet wird oder nicht. Sie müssen die Nützlichkeit eines Elements im Cache (die Einsparungen, die sich aus der Bereitstellung über den Cache ergeben) und seine Kosten (der belegte physische Arbeitsspeicher) über die Lebensdauer des Eintrags bewerten, indem Sie die verfügbaren Ressourcen (CPU und physischer Speicher) und die Anforderungen an die Arbeitsauslastung berücksichtigen. HTTP.sys versucht, nur nützliche, aktiv aufgerufene Elemente im Cache zu behalten, aber Sie können die Leistung des Webservers steigern, indem Sie den HTTP.sys Cache für bestimmte Workloads optimieren.
Im Folgenden finden Sie einige nützliche Einstellungen für den HTTP.sys Kernelmoduscache:
UriEnableCache Standardwert: 1
Ein Wert ungleich Null aktiviert die Antwort im Kernelmodus und das Fragment-Caching. Für die meisten Workloads sollte der Cache aktiviert bleiben. Erwägen Sie, den Cache zu deaktivieren, wenn Sie eine sehr geringe Antwort- und Fragmentzwischenspeicherung erwarten.
UriMaxCacheMegabyteAnzahl Standardwert: 0
Ein Wert ungleich Null, der den maximalen Arbeitsspeicher angibt, der für den Kernelmoduscache verfügbar ist. Der Standardwert 0 ermöglicht es dem System, automatisch anzupassen, wie viel Arbeitsspeicher dem Cache zur Verfügung steht.
Anmerkung Wenn Sie die Größe angeben, wird nur die maximale Größe festgelegt, und das System lässt den Cache möglicherweise nicht auf die maximal festgelegte Größe anwachsen.
Â
UriMaxUriBytes Standardwert: 262144 Byte (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 den Grenzwert erhöhen. Wenn der Arbeitsspeicher begrenzt ist und große Einträge kleinere verdrängen, kann es hilfreich sein, das Limit zu senken.
UriScavengerPeriod Standardwert: 120 Sekunden
Der HTTP.sys Cache wird regelmäßig von einem Scavenger gescannt, und Einträge, auf die zwischen den Scavenger-Scans nicht zugegriffen wird, werden entfernt. Wenn Sie die Scavenger-Periode auf einen hohen Wert einstellen, wird die Anzahl der Scavenger-Scans reduziert. Die Speicherauslastung des Caches kann jedoch zunehmen, da ältere, weniger häufig aufgerufene Einträge im Cache verbleiben können. Wenn Sie den Zeitraum zu niedrig einstellen, führt dies zu häufigeren Scavenger-Scans und kann zu vielen Leerungen und Cache-Abwanderungen 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\MaxConnectionsLeerlaufVerbindungenHochMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsHighMarkLeerlaufVerbindungenNiedrigMark
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
Einstellungen für den Benutzermodus
Die Einstellungen in diesem Abschnitt wirken sich auf das Verhalten von IIS-Arbeitsprozessen in Version 10.0 aus. Die meisten dieser Einstellungen befinden sich in der folgenden XML-Konfigurationsdatei:
%SystemRoot%\system32\inetsrv\config\applicationHost.config
Verwenden Sie Appcmd.exe, die IIS 10.0-Verwaltungskonsole, die WebAdministration oder die IISAdministration PowerShell-Cmdlets, um sie zu ändern. Die meisten Einstellungen werden automatisch erkannt, und sie erfordern keinen Neustart der IIS 10.0-Arbeitsprozesse oder des Webanwendungsservers. Weitere Informationen zur Datei applicationHost.config finden Sie unter 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 die 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, bemüht sich der IIS-Thread-Manager nach besten Kräften, IIS-Threadpoolthreads basierend auf ihren aktuellen Lasten gleichmäßig auf alle CPUs in allen NUMA-Knoten zu verteilen. Generell wird empfohlen, diese Standardeinstellung für NUMA-Hardware unverändert zu lassen.
Anmerkung Die ideale CPU-Einstellung unterscheidet sich von den NUMA-Knotenzuweisungseinstellungen für Arbeitsprozesse (numaNodeAssignment und numaNodeAffinityMode), 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 des Arbeitsprozesses bestimmen, auf welchem NUMA-Knoten ein Arbeitsprozess gestartet wird.
Einstellungen für das Cacheverhalten im Benutzermodus
In diesem Abschnitt werden die Einstellungen beschrieben, die sich auf das Zwischenspeicherungsverhalten in IIS 10.0 auswirken. Der Cache im Benutzermodus wird als Modul implementiert, das auf die globalen Zwischenspeicherungsereignisse lauscht, die von der integrierten Pipeline ausgelöst werden. Um den Cache im Benutzermodus 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
| Merkmal | BESCHREIBUNG | Standard |
|---|---|---|
| Aktiviert | Deaktiviert den IIS-Cache im Benutzermodus, wenn er auf False festgelegt ist. Wenn die Cachetrefferrate sehr gering ist, können Sie den Cache vollständig deaktivieren, um den Mehraufwand zu vermeiden, der mit dem Cachecodepfad verbunden ist. Durch das Deaktivieren des Benutzermoduscaches wird der Kernelmoduscache nicht deaktiviert. | Richtig |
| enableKernelCache | Deaktiviert den Kernelmoduscache, wenn er auf False festgelegt ist. | Richtig |
| maxCacheSize | Begrenzt die Cachegröße im IIS-Benutzermodus auf die angegebene Größe in Megabyte. IIS passt die Standardeinstellung abhängig vom verfügbaren Arbeitsspeicher an. Wählen Sie den Wert sorgfältig aus, basierend auf der Größe der Datei, auf die häufig zugegriffen wird, im Vergleich zur Größe des Arbeitsspeichers oder des Adressraums des IIS-Prozesses. | 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 Datensatz im Vergleich zum verfügbaren RAM ab. Durch das Zwischenspeichern großer, häufig angeforderter Dateien können die CPU-Auslastung, der Festplattenzugriff und die damit verbundenen Latenzen reduziert werden. | 262144 |
Einstellungen für das Verhalten "Komprimierung"
IIS ab Version 7.0 komprimiert standardmäßig statische Inhalte. Außerdem ist die Komprimierung von dynamischen Inhalten standardmäßig aktiviert, wenn das DynamicCompressionModule installiert ist. Die Komprimierung reduziert die Bandbreitennutzung, erhöht jedoch die CPU-Auslastung. Komprimierte Inhalte werden nach Möglichkeit im Kernelmoduscache zwischengespeichert. Ab Version 8.5 ermöglicht IIS die unabhängige Steuerung der Komprimierung für statische und dynamische Inhalte. Statischer Inhalt bezieht sich in der Regel auf Inhalte, die sich nicht ändern, z. B. GIF- oder HTM-Dateien. Dynamischer Inhalt wird in der Regel durch Skripts oder Code auf dem Server generiert, d. h. durch 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/httpKomprimierung
| Merkmal | BESCHREIBUNG | Standard |
|---|---|---|
| staticCompression-EnableCpuUsage staticCompression-DisableCpuUsage dynamicCompression-EnableCpuUsage dynamicCompression-DisableCpuUsage |
Aktiviert oder deaktiviert die Komprimierung, wenn die aktuelle prozentuale CPU-Auslastung die angegebenen Grenzwerte über- oder unterschreitet. Ab IIS 7.0 wird die Komprimierung automatisch deaktiviert, wenn die CPU im stabilen Zustand den Deaktivierungsschwellenwert überschreitet. Die Komprimierung ist aktiviert, wenn die CPU unter den Aktivierungsschwellenwert fällt. |
50, 100, 50 bzw. 90 |
| Verzeichnis | Gibt das Verzeichnis an, in dem komprimierte Versionen statischer Dateien vorübergehend gespeichert und zwischengespeichert werden. Erwägen Sie, dieses Verzeichnis vom Systemlaufwerk zu verschieben, wenn häufig darauf zugegriffen wird. | %SystemDrive%\inetpub\temp\IIS Temporär komprimierte Dateien |
| doDiskSpaceLimiting | Gibt an, ob es einen Grenzwert für den Speicherplatz gibt, den alle komprimierten Dateien belegen können. Komprimierte Dateien werden in dem Komprimierungsverzeichnis gespeichert, das durch das Verzeichnisattribut angegeben wird. | Richtig |
| maxDiskSpaceUsage | Gibt die Anzahl der Bytes an Speicherplatz an, die komprimierte Dateien im Komprimierungsverzeichnis belegen können. Diese Einstellung muss möglicherweise erhöht werden, wenn die Gesamtgröße des gesamten komprimierten Inhalts zu groß ist. |
100 MB |
system.webServer/urlKomprimierung
| Merkmal | BESCHREIBUNG | Standard |
|---|---|---|
| doStaticKompression | Gibt an, ob statische Inhalte komprimiert werden. | Richtig |
| doDynamicCompression | Gibt an, ob dynamischer Inhalt komprimiert wird. | Richtig |
Hinweis
Bei Servern mit IIS 10.0, die eine niedrige durchschnittliche CPU-Auslastung aufweisen, sollten Sie die Komprimierung für dynamische Inhalte aktivieren, insbesondere wenn die Antworten groß sind. Dies sollte zunächst in einer Testumgebung erfolgen, um die Auswirkungen auf die CPU-Auslastung von der Baseline aus zu bewerten.
Optimieren der Standarddokumentliste
Das Standarddokumentmodul verarbeitet HTTP-Anforderungen für das Stammverzeichnis eines Verzeichnisses und übersetzt sie in Anforderungen für eine bestimmte Datei, z. B. Default.htm oder Index.htm. Im Durchschnitt durchlaufen etwa 25 Prozent aller Anfragen im Internet den Standarddokumentpfad. Dies ist für die einzelnen Standorte sehr unterschiedlich. Wenn eine HTTP-Anforderung keinen Dateinamen angibt, durchsucht das Standarddokumentmodul die Liste der zulässigen Standarddokumente nach jedem Namen im Dateisystem. Dies kann sich negativ auf die Leistung auswirken, insbesondere wenn zum Erreichen des Inhalts ein Netzwerk-Roundtrip oder das Berühren eines Datenträgers erforderlich ist.
Sie können den Aufwand vermeiden, indem Sie Standarddokumente selektiv deaktivieren und die Liste der Dokumente reduzieren oder sortieren. Für Websites, die ein Standarddokument verwenden, sollten Sie die Liste auf die verwendeten Standarddokumenttypen reduzieren. Ordnen Sie die Liste außerdem so an, dass sie mit dem Namen der Standarddokumentdatei beginnt, auf die am häufigsten zugegriffen wird.
Sie können das Standardverhalten von Dokumenten 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 einen hybriden Ansatz, der Standarddokumente nur dort zulässt, wo sie notwendig sind, und die Liste für jede URL auf den richtigen Dateinamen setzt.
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
| Merkmal | BESCHREIBUNG | Standard |
|---|---|---|
| aktiviert | Gibt an, dass Standarddokumente aktiviert sind. | Richtig |
<files>-Element |
Gibt die Dateinamen an, die als Standarddokumente konfiguriert sind. | Die Standardliste besteht aus Default.htm, Default.asp, Index.htm, Index.html, Iisstart.htmund Default.aspx. |
Zentrale binäre Protokollierung
Wenn die Serversitzung über zahlreiche 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, was zu Leistungs- und Skalierbarkeitsproblemen führt. Die zentralisierte binäre Protokollierung minimiert die Menge der Systemressourcen, die für die Protokollierung verwendet werden, und stellt gleichzeitig detaillierte Protokolldaten für Organisationen bereit, die dies benötigen. Für das Analysieren von Protokollen im binären Format ist ein Nachbearbeitungstool erforderlich.
Sie können die zentrale Binärprotokollierung aktivieren, indem Sie das centralLogFileMode-Attribut auf CentralBinary und das enabled-Attribut auf True festlegen. Erwägen Sie, den Speicherort der zentralen Protokolldatei von der Systempartition auf ein dediziertes Protokollierungslaufwerk zu verschieben, um Konflikte zwischen Systemaktivitäten und Protokollierungsaktivitäten zu vermeiden.
system.applicationHost/Protokoll
| Merkmal | BESCHREIBUNG | Standard |
|---|---|---|
| centralLogFileMode | Gibt den Protokollierungsmodus für einen Server an. Ändern Sie diesen Wert in CentralBinary, um die zentrale binäre Protokollierung zu aktivieren. | Standort |
system.applicationHost/log/centralBinaryLogFile
| Merkmal | BESCHREIBUNG | Standard |
|---|---|---|
| aktiviert | Gibt an, ob die zentrale binäre Protokollierung aktiviert ist. | Falsch |
| Verzeichnis | Gibt das Verzeichnis an, in das Protokolleinträge geschrieben werden. | %SystemDrive%\inetpub\logs\LogFiles |
Anwendungs- und Site-Optimierungen
Die folgenden Einstellungen beziehen sich auf Anwendungspool- und Standortoptimierungen.
system.applicationHost/applicationPools/applicationPoolDefaults
| Merkmal | BESCHREIBUNG | Standard |
|---|---|---|
| queueLength (englisch) | Gibt HTTP.sys an, wie viele Anforderungen für einen Anwendungspool in die Warteschlange eingereiht 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. Erwägen Sie, diese Option für Anwendungen zu erhöhen, die mit Back-End-Datenspeichern mit hoher Latenz kommunizieren, wenn 503-Fehler beobachtet werden. |
1000 |
| enable32BitAppOnWin64 | Bei True kann eine 32-Bit-Anwendung auf einem Computer ausgeführt werden, der über einen 64-Bit-Prozessor verfügt. Erwägen Sie, den 32-Bit-Modus zu aktivieren, wenn der Speicherverbrauch ein Problem darstellt. Da die Zeigergrößen und Befehlsgrößen kleiner sind, verwenden 32-Bit-Anwendungen weniger Arbeitsspeicher als 64-Bit-Anwendungen. Der Nachteil beim Ausführen von 32-Bit-Anwendungen auf einem 64-Bit-Computer besteht darin, dass der Adressraum im Benutzermodus auf 4 GB begrenzt ist. |
Falsch |
system.applicationHost/sites/VirtualDirectoryDefault
| Merkmal | BESCHREIBUNG | Standard |
|---|---|---|
| allowSubDirConfig | Gibt an, ob IIS nach web.config Dateien in Inhaltsverzeichnissen sucht, die niedriger als die aktuelle Ebene sind (True), oder ob nicht nach web.config Dateien in Inhaltsverzeichnissen gesucht wird, die niedriger als die aktuelle Ebene sind (False). Durch das Auferlegen einer einfachen Einschränkung, die die Konfiguration nur in virtuellen Verzeichnissen zulässt, kann IISÂ 10.0 wissen, dass nicht nach einer Konfigurationsdatei gesucht werden soll, es sei denn, /<name>.htm handelt sich um ein virtuelles Verzeichnis. Das Überspringen der zusätzlichen Dateivorgänge kann die Leistung von Websites mit einer sehr großen Anzahl von statischen Inhalten, auf die nach dem Zufallsprinzip zugegriffen wird, erheblich verbessern. | Richtig |
Verwalten von IIS 10.0-Modulen
IIS 10.0 wurde in mehrere, vom Benutzer erweiterbare Module integriert, um eine modulare Struktur zu unterstützen. Diese Faktorisierung ist mit geringen Kosten verbunden. Für jedes Modul muss die integrierte Pipeline das Modul für jedes Ereignis aufrufen, das für das Modul relevant ist. Dies geschieht unabhängig davon, ob das Modul eine Arbeit ausfü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, enthält möglicherweise nur die folgenden fünf Module: UriCacheModule, HttpCacheModule, StaticFileModule, AnonymousAuthenticationModule und HttpLoggingModule.
Um Module aus applicationHost.configzu entfernen, entfernen Sie zusätzlich zum Entfernen der Moduldeklaration in system.webServer/globalModules alle Verweise auf das Modul aus den Abschnitten system.webServer/handlers und system.webServer/modules.
Klassische ASP-Einstellungen
Zu den Hauptkosten für die Verarbeitung einer klassischen ASP-Anforderung gehören das Initialisieren eines Skriptmoduls, das Kompilieren des angeforderten ASP-Skripts in eine ASP-Vorlage und das Ausführen der Vorlage in der Skript-Engine. Während die Kosten für die Vorlagenausführung von der Komplexität des angeforderten ASP-Skripts abhängen, kann das klassische ASP-Modul IIS Skriptmodule im Arbeitsspeicher und Vorlagen sowohl im Arbeitsspeicher als auch im Datenträger zwischenspeichern (nur wenn der Vorlagencache im Arbeitsspeicher überläuft), 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
| Merkmal | BESCHREIBUNG | Standard |
|---|---|---|
| diskTemplateCacheVerzeichnis | Der Name des Verzeichnisses, das ASP zum Speichern kompilierter Vorlagen verwendet, wenn der In-Memory-Cache überläuft. Empfehlung: Legen Sie diese Option auf ein Verzeichnis fest, das nicht häufig verwendet wird, z. B. ein Laufwerk, das nicht für das Betriebssystem, das IIS-Protokoll oder andere häufig verwendete Inhalte freigegeben ist. |
%SystemDrive%\inetpub\temp\ASP kompilierte Vorlagen |
| maxDiskTemplateCacheFiles | Gibt die maximale Anzahl kompilierter ASP-Vorlagen an, die auf dem Datenträger zwischengespeichert werden können. Empfehlung: Legen Sie den Maximalwert 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 Anzahl auf mindestens so viele fest, wie die Anzahl der häufig angeforderten ASP-Skripts, die von einem Anwendungspool bereitgestellt werden. Legen Sie nach Möglichkeit 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 Anzahl auf mindestens so viele fest, wie die Anzahl der häufig angeforderten ASP-Skripts, die von einem Anwendungspool bereitgestellt werden. Legen Sie nach Möglichkeit so viele Skriptmodule fest, wie das Speicherlimit zulässt. |
250 |
system.webServer/asp/grenzwerte
| Merkmal | BESCHREIBUNG | Standard |
|---|---|---|
| prozessorThreadMax | Gibt die maximale Anzahl von Arbeitsthreads pro Prozessor an, die ASP erstellen kann. Erhöhen, wenn die aktuelle Einstellung nicht ausreicht, um die Last zu verarbeiten, was zu Fehlern beim Verarbeiten von Anforderungen oder zu einer unzureichenden Auslastung der CPU-Ressourcen führen kann. | 25 |
system.webServer/asp/comPlus
| Merkmal | BESCHREIBUNG | Standard |
|---|---|---|
| executeInMta | Legen Sie diesen Wert auf True fest, wenn Fehler oder Fehler erkannt werden, während IIS ASP-Inhalte bereitstellt. Dies kann z. B. beim Hosten mehrerer isolierter Websites der Fall sein, bei denen jeder Standort unter einem eigenen Arbeitsprozess ausgeführt wird. Fehler werden in der Regel von COM+ in der Ereignisanzeige gemeldet. Mit dieser Einstellung wird das Multithread-Apartmentmodell in ASP. | Falsch |
ASP.NET Einstellung für Parallelität
ASP.NET 3.5
Standardmäßig schränkt ASP.NET die Parallelität von Anforderungen ein, um den Speicherverbrauch im stabilen Zustand auf dem Server zu reduzieren. Anwendungen mit hoher Parallelität müssen möglicherweise einige Einstellungen anpassen, um die Gesamtleistung zu verbessern. Sie können diese Einstellung in aspnet.config Datei ändern:
<system.web>
<applicationPool maxConcurrentRequestsPerCPU="5000"/>
</system.web>
Die folgende Einstellung ist nützlich, um Ressourcen auf einem System vollständig zu nutzen:
maxConcurrentRequestPerCpu Standardwert: 5000
Diese Einstellung begrenzt die maximale Anzahl gleichzeitig ausgeführter ASP.NET Anforderungen auf einem System. Der Standardwert ist konservativ, um den Speicherverbrauch ASP.NET Anwendungen zu reduzieren. Erwägen Sie, diesen Grenzwert für Systeme zu erhöhen, auf denen Anwendungen ausgeführt werden, die lange, synchrone E/A-Vorgänge ausführen. Andernfalls kann es bei Benutzern zu hohen Latenzzeiten aufgrund von Warteschlangen- oder Anforderungsfehlern kommen, die durch Überschreiten der Warteschlangengrenzwerte bei hoher Auslastung bei Verwendung der Standardeinstellung verursacht werden.
ASP.NET 4.6
Neben der Einstellung maxConcurrentRequestPerCpu bietet ASP.NET 4.7 auch Einstellungen zur Verbesserung der Performance in den Anwendungen, die stark auf asynchronen Betrieb angewiesen sind. Die Einstellung kann in aspnet.config Datei geändert werden.
<system.web>
<applicationPool percentCpuLimit="90" percentCpuLimitMinActiveRequestPerCpu="100"/>
</system.web>
- percentCpuLimit Standardwert: 90 Bei einer asynchronen Anforderung treten Skalierbarkeitsprobleme auf, wenn eine große Last (über die Hardwarefunktionen hinaus) auf ein solches Szenario übertragen wird. Das Problem liegt in der Art der Zuordnung in asynchronen Szenarien. Unter diesen Bedingungen erfolgt die Zuordnung, wenn der asynchrone Vorgang gestartet wird, und er wird verbraucht, wenn er abgeschlossen ist. Zu diesem Zeitpunkt ist es sehr gut möglich, dass die Objekte von GC in Generation 1 oder 2 verschoben wurden. In diesem Fall wird durch Erhöhen der Last eine Erhöhung auf Anforderung pro Sekunde (RPS) bis zu einem bestimmten Punkt angezeigt. Sobald wir diesen Punkt überschritten haben, wird die Zeit, die wir in GC verbringen, zu einem Problem und die RPS beginnen zu sinken, was sich negativ auf die Skalierung auswirkt. Um das Problem zu beheben, werden Anforderungen an die ASP.NET native Warteschlange gesendet, wenn die CPU-Auslastung die percentCpuLimit-Einstellung überschreitet.
- percentCpuLimitMinActiveRequestPerCpu Standardwert: 100 CPU-Drosselung (percentCpuLimit-Einstellung) basiert nicht auf der Anzahl der Anforderungen, sondern darauf, wie teuer sie sind. Infolgedessen kann es nur wenige CPU-intensive Anforderungen geben, die eine Sicherung in der nativen Warteschlange verursachen, ohne dass sie außer eingehenden Anforderungen geleert werden kann. Um dieses Problem zu lösen, kann percentCpuLimitMinActiveRequestPerCpu verwendet werden, um sicherzustellen, dass eine Mindestanzahl von Anforderungen verarbeitet wird, bevor die Drosselung einsetzt.
Arbeitsprozess und Recyclingoptionen
Sie können Optionen für die Wiederverwendung von IIS-Arbeitsprozessen konfigurieren und praktische Lösungen für akute Situationen oder Ereignisse bereitstellen, ohne dass ein Eingreifen oder Zurücksetzen eines Diensts oder Computers erforderlich ist. Zu solchen Situationen und Ereignissen gehören Speicherverluste, zunehmende Speicherauslastung oder nicht reagierende oder inaktive Arbeitsprozesse. Unter normalen Bedingungen sind Recyclingoptionen möglicherweise nicht erforderlich, und das Recycling kann deaktiviert werden oder das System kann so konfiguriert werden, dass es nur sehr selten recycelt wird.
Sie können die Prozesswiederverwendung für eine bestimmte Anwendung aktivieren, indem Sie dem recycling /periodicRestart-Element Attribute hinzufügen. Das Wiederverwendungsereignis kann durch verschiedene Ereignisse ausgelöst werden, z. B. durch die Speicherauslastung, eine feste Anzahl von Anforderungen und einen festen Zeitraum. Wenn ein Arbeitsprozess wiederverwendet wird, werden die in der Warteschlange befindlichen und ausgeführten Anforderungen leergewalzt, und gleichzeitig wird ein neuer Prozess gestartet, um neue Anforderungen zu verarbeiten. Das recycling/periodicRestart-Element gilt pro Anwendung, was bedeutet, dass jedes Attribut in der folgenden Tabelle pro Anwendung partitioniert wird.
system.applicationHost/applicationPools/ApplicationPoolDefaults/recycling/periodicRestart
| Merkmal | BESCHREIBUNG | Standard |
|---|---|---|
| Gedächtnis | Aktivieren Sie die Prozesswiederverwendung, wenn der Verbrauch des virtuellen Speichers 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 aufgrund von Fehlern aufgrund von nicht genügend Arbeitsspeicher zu vermeiden. | 0 |
| privateMemory | Aktivieren Sie die Prozesswiederverwendung, wenn private Speicherbelegungen einen angegebenen Grenzwert in Kilobyte überschreiten. | 0 |
| Aufforderungen | Aktivieren Sie das Prozessrecycling nach einer bestimmten Anzahl von Anforderungen. | 0 |
| Zeit | Aktivieren Sie das Prozessrecycling nach einem bestimmten Zeitraum. | 29:00:00 |
Dynamische Optimierung der Auslagerungsausgabe von Arbeitsprozessen
Ab Windows Server 2012 R2 bietet IIS die Möglichkeit, Arbeitsprozesse so zu konfigurieren, dass sie angehalten werden, nachdem sie sich eine Zeit lang im Leerlauf befunden haben (zusätzlich zu der Option zum Beenden, die seit IIS 7 vorhanden ist).
Der Hauptzweck sowohl der Funktionen zum Auslagern von Arbeitsprozessen im Leerlauf als auch bei der Beendigung von Arbeitsprozessen im Leerlauf besteht darin, die Speicherauslastung auf dem Server zu sparen, da ein Standort viel Arbeitsspeicher verbrauchen kann, selbst wenn er nur da sitzt und lauscht. Abhängig von der auf der Website verwendeten Technologie (statischer Inhalt im Vergleich zu ASP.NET im Vergleich zu anderen Frameworks) kann der verwendete Arbeitsspeicher zwischen etwa 10 MB und Hunderten von MB liegen, und dies bedeutet, dass, wenn Ihr Server mit vielen Websites konfiguriert ist, das Ermitteln der effektivsten Einstellungen für Ihre Websites die Leistung sowohl aktiver als auch angehaltener Websites erheblich verbessern kann.
Bevor wir ins Detail gehen, müssen wir im Hinterkopf behalten, dass es wahrscheinlich am besten ist, die Websites einfach so einzustellen, dass sie nie angehalten oder beendet werden, wenn es keine Speicherbeschränkungen gibt. Schließlich ist es wenig sinnvoll, einen Arbeitsprozess 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 instabil, kann das Festlegen der Website, dass sie im Leerlauf beendet wird, eine schnelle Alternative zur Behebung des Codefehlers sein. Das ist nichts, was wir befürworten würden, aber im Notfall könnte es besser sein, diese Funktion als Bereinigungsmechanismus zu verwenden, während eine dauerhaftere Lösung in Arbeit ist.]
Ein weiterer zu berücksichtigender Faktor besteht darin, dass, wenn der Standort viel Arbeitsspeicher verwendet, der Unterbrechungsprozess selbst einen Tribut fordert, da der Computer die vom Arbeitsprozess verwendeten Daten auf den Datenträger schreiben muss. Wenn der Arbeitsprozess einen großen Teil des Arbeitsspeichers verwendet, kann das Anhalten teurer sein als die Kosten für das Warten auf den Wiederstart.
Um das Feature zum Anhalten von Arbeitsprozessen optimal zu nutzen, müssen Sie Ihre Websites in jedem Anwendungspool überprüfen und entscheiden, welche angehalten, welche beendet und welche auf unbestimmte Zeit aktiv sein sollen. Für jede Aktion und jeden Standort müssen Sie den idealen Timeout-Zeitraum ermitteln.
Im Idealfall sind die Websites, die Sie für die Sperrung oder Beendigung konfigurieren, diejenigen, die jeden Tag Besucher haben, aber nicht genug, um es zu rechtfertigen, sie ständig aktiv zu halten. Dabei handelt es sich in der Regel um Websites mit etwa 20 Unique Visitors pro Tag oder weniger. Sie können die Verkehrsmuster anhand der Protokolldateien der Website analysieren und den durchschnittlichen täglichen Datenverkehr berechnen.
Denken Sie daran, dass ein bestimmter Benutzer, sobald er sich mit der Website verbindet, in der Regel mindestens eine Weile auf der Website bleibt und zusätzliche Anfragen stellt, sodass das bloße Zählen der täglichen Anfragen möglicherweise nicht genau die tatsächlichen Verkehrsmuster widerspiegelt. Um einen genaueren Messwert zu erhalten, können Sie auch ein Tool wie Microsoft Excel verwenden, um die durchschnittliche Zeit zwischen den Anforderungen zu berechnen. Beispiel:
| Nummer | Anfrage-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 | / QuelleSilverLight/GeosourcewebService/Service.asmx | 10:23 | 0:11 |
| 6 | / QuelleSilverLight/Geosource.web/GeoSearchServer...¦. | 11:50 | 1:27 |
| 7 | /rest/Services/CachedServices/Silverlight_load_la...¦ | 1,250 | 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 Anfragen von Benutzern, und die obige Tabelle zeigt, dass in einem Zeitraum von 4 Stunden insgesamt 4 eindeutige Sitzungen stattgefunden haben. Mit den Standardeinstellungen für das Anhalten des Anwendungspools durch Arbeitsprozesse würde die Website nach dem Standardtimeout von 20 Minuten beendet, was bedeutet, dass jeder dieser Benutzer den Zyklus zum Starten der Website erleben würde. Dies macht es zu einem idealen Kandidaten für das Anhalten von Arbeitsprozessen, da sich die Website die meiste Zeit im Leerlauf befindet und das Anhalten Ressourcen sparen würde, sodass die Benutzer die Website fast sofort erreichen können.
Ein letzter und sehr wichtiger Hinweis dazu ist, dass die Festplattenleistung für diese Funktion entscheidend 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 sehr zu empfehlen, und Sie sollten sicherstellen, dass die Windows-Auslagerungsdatei darauf gespeichert ist (wenn 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, empfehlen wir außerdem, die Größe der Auslagerungsdatei so zu fixieren, dass die Auslagerungsdaten ohne Dateigrößenänderung in die Datei geschrieben werden können. Die Größenänderung von Auslagerungsdateien kann auftreten, wenn das Betriebssystem Daten in der Auslagerungsdatei speichern muss, da Windows standardmäßig so konfiguriert ist, dass die Größe je nach Bedarf automatisch angepasst wird. Indem Sie die Größe auf eine feste Größe festlegen, können Sie eine Größenänderung verhindern und die Leistung erheblich verbessern.
Um die Größe einer vordefinierten Auslagerungsdatei zu konfigurieren, müssen Sie die ideale Größe berechnen, die davon abhängt, wie viele Websites Sie anhalten und wie viel Arbeitsspeicher sie verbrauchen. Wenn der Durchschnitt für einen aktiven Arbeitsprozess 200 MB beträgt und Sie 500 Websites auf den Servern haben, die angehalten werden, sollte die Auslagerungsdatei mindestens (200 * 500) MB über der Basisgröße der Auslagerungsdatei liegen (also Basis + 100 GB in unserem Beispiel).
Hinweis
Wenn Websites angehalten werden, verbrauchen sie jeweils etwa 6 MB, sodass die Speicherauslastung in unserem Fall etwa 3 GB betragen würde, wenn alle Websites angehalten werden. In Wirklichkeit werden Sie jedoch wahrscheinlich nie alle gleichzeitig suspendiert haben.
Optimierungsparameter für Transport Layer Security
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 es sich um einen vollständigen Handshake handelt. Die Wiederherstellung, Verschlüsselung und Entschlüsselung erhöhen die Kosten ebenfalls. Um eine bessere TLS-Leistung zu erzielen, gehen Sie wie folgt vor:
Aktivieren Sie HTTP-Keepalives für TLS-Sitzungen. Dadurch entfallen die Kosten für die Sitzungseinrichtung.
Verwenden Sie Sitzungen bei Bedarf wieder, insbesondere bei Datenverkehr ohne Keep-Alive.
Wenden Sie die Verschlüsselung selektiv nur auf Seiten oder Teile der Website an, für die sie erforderlich ist, und nicht auf die gesamte Website.
Hinweis
- Größere Schlüssel bieten mehr Sicherheit, verbrauchen aber auch mehr CPU-Zeit.
- Möglicherweise müssen nicht alle Komponenten verschlüsselt werden. Das Mischen von einfachem HTTP und HTTPS kann jedoch zu einer Popup-Warnung 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. Wenn Sie eine private ISAPI-Erweiterung schreiben, stellen Sie sicher, dass sie für Leistung und Ressourcennutzung geschrieben wurde.
Richtlinien für die Optimierung von verwaltetem Code
Das integrierte Pipelinemodell in IIS 10.0 ermöglicht ein hohes Maß an Flexibilität und Erweiterbarkeit. Benutzerdefinierte Module, die in systemeigenem oder verwaltetem Code implementiert sind, können in die Pipeline eingefügt werden, oder sie können vorhandene Module ersetzen. Obwohl dieses Erweiterungsmodell Komfort und Einfachheit bietet, sollten Sie vorsichtig sein, bevor Sie neue verwaltete Module einfügen, die sich in globale Ereignisse einklinken. Das Hinzufügen eines global verwalteten Moduls bedeutet, dass alle Anforderungen, einschließlich statischer Dateianforderungen, verwalteten Code betreffen müssen. Benutzerdefinierte Module sind anfällig für Ereignisse wie die Garbage Collection. Darüber hinaus verursachen benutzerdefinierte Module erhebliche CPU-Kosten aufgrund des Marshallings von Daten zwischen systemeigenem und verwaltetem Code. Wenn möglich, sollten Sie preCondition für das verwaltete Modul auf managedHandler festlegen.
Um eine bessere Leistung beim Kaltstart zu erzielen, stellen Sie sicher, dass Sie die ASP.NET Website vorkompilieren oder die IIS-Anwendungsinitialisierungsfunktion nutzen, um die Anwendung aufzuwärmen.
Wenn der Sitzungsstatus nicht benötigt wird, stellen Sie sicher, dass Sie ihn für jede Seite deaktivieren.
Wenn es viele E/A-gebundene Vorgänge gibt, versuchen Sie, eine asynchrone Version relevanter APIs zu verwenden, die Ihnen eine viel bessere Skalierbarkeit bietet.
Auch die ordnungsgemäße Verwendung des Ausgabecaches steigert die Leistung Ihrer Website.
Wenn Sie mehrere Hosts ausführen, die ASP.NET Skripts im isolierten Modus (ein Anwendungspool pro Site) enthalten, überwachen Sie die Speicherauslastung. 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.
Weitere Probleme, die sich auf die IIS-Leistung auswirken
Die folgenden Probleme können sich auf die IIS-Leistung auswirken:
Installation von Filtern, die nicht Cache-fähig sind
Die Installation eines Filters, der nicht HTTP-Cache-fähig ist, führt dazu, dass IIS die Zwischenspeicherung vollständig deaktiviert, was zu einer schlechten Leistung führt. ISAPI-Filter, die vor IIS 6.0 geschrieben wurden, können dieses Verhalten verursachen.
CGI-Anfragen (Common Gateway Interface)
Aus Leistungsgründen wird die Verwendung von CGI-Anwendungen zum Verarbeiten von Anforderungen mit IIS nicht empfohlen. Das Erstellen und Löschen von CGI-Prozessen ist häufig mit einem erheblichen Aufwand verbunden. Bessere Alternativen sind die Verwendung von FastCGI, ISAPI-Anwendungsskripten und ASP- oder ASP.NET-Skripten. Für jede dieser Optionen ist die Isolierung verfügbar.