Anwenden der IIS-Konfigurationseinstellungen
Standardmäßig öffnen die SOAP-, HTTP- und HTTP-basierten WCF-Adapter (und .NET im Allgemeinen) nur zwei gleichzeitige HTTP-Verbindungen von jedem BizTalk-Host instance zu einem bestimmten Zielserver. Wenn Sie beispielsweise über einen SOAP-Sendeport verfügen, der Nachrichten an http://www.contoso.com/SomeWebService.asmxsendet, öffnet jeder Host instance, der auf jedem BizTalk Server ausgeführt wird, standardmäßig nur zwei gleichzeitige HTTP-Verbindungen mit www.contoso.com, unabhängig davon, wie viele Nachrichten gesendet werden müssen.
Diese Einstellung entspricht dem IETF-RFC für die HTTP 1.1-Spezifikation und ist zwar für Benutzerszenarien geeignet, aber nicht für die Kommunikation zwischen Server und Server mit hohem Durchsatz optimiert. Die Standardeinstellung drosselt ausgehende SOAP- und HTTP-Aufrufe an jeden Zielserver effektiv auf zwei gleichzeitige Senden von BizTalk Server Host instance.
Konfigurieren ASP.NET MaxConcurrentRequests für den integrierten IIS 7.0-Modus
Wenn ASP.NET 2.0 in IIS 7.0 im integrierten Modus gehostet wird, wird die Verwendung von Threads anders behandelt als in IIS 6.0 oder in IIS 7.0 im klassischen Modus. Wenn ASP.NET 2.0 in IIS 7.0 im integrierten Modus gehostet wird, schränkt ASP.NET 2.0 die Anzahl gleichzeitig ausgeführter Anforderungen anstelle der Anzahl von Threads ein, die gleichzeitig Anforderungen ausführen. Bei synchronen Szenarien wird dadurch indirekt die Anzahl von Threads eingeschränkt, da die Anzahl der Anforderungen mit der Anzahl von Threads identisch ist. Bei asynchronen Szenarien ist die Anzahl der Anforderungen und Threads jedoch wahrscheinlich sehr unterschiedlich, da Sie weit mehr Anforderungen als Threads haben könnten. Wenn Sie ASP.NET 2.0 unter IIS 7.0 im integrierten Modus ausführen, werden die minFreeThreads und minLocalRequestFreeThreads des "httpRuntime"-Elements im machine.config ignoriert. Für den integrierten IIS 7.0-Modus bestimmt ein DWORD mit dem Namen MaxConcurrentRequestsPerCPU innerhalb HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0 die Anzahl gleichzeitiger Anforderungen pro CPU. Standardmäßig ist der Registrierungsschlüssel nicht vorhanden, und die Anzahl der Anforderungen pro CPU ist auf 12 beschränkt. .NET Framework 3.5 SP1 enthält ein Update auf die v2.0-Binärdateien, das das Konfigurieren von IIS-Anwendungspools über die aspnet.config-Datei unterstützt. Diese Konfiguration gilt nur für den integrierten Modus (klassisch/ISAPI-Modus ignoriert diese Einstellungen). Der neue aspnet.config Konfigurationsabschnitt mit Standardwerten ist unten aufgeführt:
<system.web>
<applicationPool maxConcurrentRequestsPerCPU="12" maxConcurrentThreadsPerCPU="0" requestQueueLimit="5000"/>
</system.web>
Als Faustregel sollte MaxConcurrentRequestsPerCPU auf einen sehr großen Wert festgelegt werden, z. B. 5000.
Im integrierten IIS 7.0-Modus werden die Parameter maxWorkerThreads und maxIoThreads im Abschnitt "processModel" der machine.config-Datei nicht verwendet, um die Anzahl der ausgeführten Anforderungen per se zu steuern, aber sie werden weiterhin verwendet, um die Größe des CLR-Threadpools zu steuern, der von ASP.NET verwendet wird. Wenn der Abschnitt "processModel" des machine.config über "autoConfig=true" (die Standardeinstellung) verfügt, erhält der Anwendungspool bis zu 100 Workerthreads (MaxWorkerThreads) pro logischer CPU. Ein gemeinsamer Standardserver mit 2 Dual-Core-CPUs hätte also 400 MaxWorkerThreads. Dies sollte für alle bis auf die anspruchsvollsten Anwendungen ausreichend sein.
Weitere Informationen zum Konfigurieren ASP.NET Threadnutzung in IIS 7.0 und 6.0 finden Sie im Blog von Thomas Marquardt zur ASP.NET Threadverwendung in IIS 7.0 und 6.0 (https://go.microsoft.com/fwlink/?LinkId=157518).
Protokollieren Sie nur wichtige Informationen oder deaktivieren Sie die IIS-Protokollierung vollständig.
Die IIS-Protokollierung sollte in einer Produktionsumgebung minimiert oder sogar deaktiviert werden. Führen Sie die folgenden Schritte aus, um die Protokollierung zu deaktivieren:
Klicken Sie auf Start, zeigen Sie auf Alle Programme, klicken Sie auf Verwaltung, und klicken Sie dann auf Internetinformationsdienste-Manager (IIS).
Klicken Sie im Bereich Verbindungen , um Websites zu erweitern, klicken Sie auf die Website, für die Sie die Protokollierung deaktivieren möchten, klicken Sie auf Featureansicht, und doppelklicken Sie dann auf die Protokollierungsfunktion .
Klicken Sie im Bereich Aktionen auf Deaktivieren, um die Protokollierung für diese Website zu deaktivieren.
Deaktivieren des IIS ASP-Debuggens in Produktionsumgebungen
DAS IIS-ASP-Debuggen sollte in einer Produktionsumgebung deaktiviert sein. Führen Sie die folgenden Schritte aus, um das IIS ASP-Debuggen zu deaktivieren:
Klicken Sie auf Start, zeigen Sie auf Alle Programme, klicken Sie auf Verwaltung, und klicken Sie dann auf Internetinformationsdienste-Manager (IIS).
Klicken Sie im Bereich Verbindungen , um Websites zu erweitern, klicken Sie auf die Website, für die Sie ASP-Debugging deaktivieren möchten, klicken Sie auf Featuresansicht, und doppelklicken Sie dann auf das ASP-Feature .
Klicken Sie, um Kompilierung zu erweitern, klicken Sie, um Debugeigenschaften zu erweitern, und vergewissern Sie sich, dass sowohl Clientseitiges Debuggen aktivieren als auch Serverseitiges Debuggen aktivieren auf False festgelegt sind.
Klicken Sie bei Bedarf im Bereich Aktionen auf Anwenden.
Deaktivieren Sie das Debuggen für ASP.NET Anwendungen und Webdienste, indem Sie den <Kompilierungsabschnitt debug="false"> in der web.config-Datei für die Webanwendung angeben.
Optimieren des Werts der EIGENSCHAFT "ASP Threads Pro Prozessorlimit"
Die Eigenschaft ASP Threads Per Processor Limit gibt die maximale Anzahl von Workerthreads pro Prozessor an, die IIS erstellt. Erhöhen Sie den Wert für das Grenzwert für Threads pro Prozessor, bis die Prozessorauslastung mindestens 50 Prozent oder höher erreicht. Diese Einstellung kann die Skalierbarkeit Ihrer Webanwendungen und die Leistung Ihres Servers im Allgemeinen erheblich beeinflussen. Da diese Eigenschaft die maximale Anzahl von ASP-Anforderungen definiert, die gleichzeitig ausgeführt werden können, sollte diese Einstellung beim Standardwert verbleiben, es sei denn, Ihre ASP-Anwendungen führen erweiterte Aufrufe externer Komponenten durch. In diesem Fall können Sie den Wert von Threads pro Prozessorlimit erhöhen. Dadurch kann der Server mehr Threads erstellen, um mehr gleichzeitige Anforderungen zu verarbeiten. Der Standardwert für Threads pro Prozessor ist 25. Der maximal empfohlene Wert für diese Eigenschaft ist 100.
Führen Sie die folgenden Schritte aus, um den Wert für das Limit für Threads pro Prozessor zu erhöhen:
Klicken Sie auf Start, zeigen Sie auf Alle Programme, klicken Sie auf Verwaltung, und klicken Sie dann auf Internetinformationsdienste-Manager (IIS).
Wählen Sie im Bereich Verbindungen den Webserver aus, klicken Sie auf Featureansicht, und doppelklicken Sie dann auf das ASP-Feature .
Klicken Sie hier, um Die Eigenschaften von Grenzwerten unter Verhalten zu erweitern, klicken Sie auf Threads pro Prozessorlimit, geben Sie den gewünschten Wert für Threads pro Prozessorlimit ein, und klicken Sie im Bereich Aktionen auf Anwenden.
Weitere Informationen zum Ändern der Eigenschaften im <limits-Element> des ASP-Elements> von IIS 7.0 <finden Sie unter ASP-Grenzwerte <> (https://go.microsoft.com/fwlink/?LinkId=157483).
Hinweis
Da diese Eigenschaft nur auf Serverebene angewendet werden kann, wirkt sich die Änderung dieser Eigenschaft auf alle Websites aus, die auf dem Server ausgeführt werden.
Hinweis
Die ASP Threads Per Processor Limit-Eigenschaft für IIS 7.0 ersetzt die IIS 6.0 ASPProcessorThreadMax ASP Metabase-Einstellung. Informationen zur ASP-Metabasiseinstellung für IIS 6.0 ASPProcessorThreadMax finden Sie unter Optimieren der ASP-Metabasiseinstellungen (https://go.microsoft.com/fwlink/?LinkId=158834) auf MSDN.
Optimieren des Werts der ASP-Warteschlangenlängeneigenschaft
Das Ziel der Optimierung dieser Eigenschaft besteht darin, eine gute Antwortzeit sicherzustellen und gleichzeitig zu minimieren, wie oft der Server den HTTP-Fehler 503 (Server too Busy) an Clients sendet, wenn die ASP-Anforderungswarteschlange voll ist. Wenn der Wert der ASP-Warteschlangenlängeneigenschaft zu niedrig ist, sendet der Server den HTTP 503-Fehler mit größerer Häufigkeit. Wenn der Wert der ASP-Warteschlangenlängeneigenschaft zu hoch ist, nehmen Benutzer möglicherweise wahr, dass der Server nicht reagiert, wenn ihre Anforderung tatsächlich in der Warteschlange wartet. Wenn Sie die Warteschlange in Zeiten mit hohem Datenverkehr beobachten, sollten Sie ein Muster von Webanforderungsspitzen und -tälern erkennen. Notieren Sie sich den Spitzenwert, und legen Sie den Wert der ASP Queue Length-Eigenschaft direkt über dem Spitzenwert fest. Verwenden Sie die Warteschlange, um kurzfristige Spitzen zu behandeln, die Antwortzeit sicherzustellen und das System zu drosseln, um eine Überlastung zu vermeiden, wenn anhaltende, unerwartete Spitzen auftreten. Wenn Sie keine Daten zum Anpassen der ASP Queue Length-Eigenschaft haben, ist ein guter Ausgangspunkt, ein Verhältnis von 1:1 Warteschlangen auf die Gesamtthreads festzulegen. Wenn beispielsweise die Eigenschaft ASP Threads Per Processor Limit auf 25 festgelegt ist und Sie über vier Prozessoren (4 * 25 = 100 Threads) verfügen, legen Sie die ASP Queue Length-Eigenschaft auf 100 fest, und optimieren Sie von dort aus.
Führen Sie die folgenden Schritte aus, um den Wert für die Queue Length-Eigenschaft zu erhöhen:
Klicken Sie auf Start, zeigen Sie auf Alle Programme, klicken Sie auf Verwaltung, und klicken Sie dann auf Internetinformationsdienste-Manager (IIS).
Wählen Sie im Bereich Verbindungen den Webserver aus, klicken Sie auf Featureansicht, und doppelklicken Sie dann auf das ASP-Feature .
Klicken Sie, um Grenzwerte eigenschaften unter Verhalten zu erweitern, klicken Sie auf Warteschlangenlänge, geben Sie den gewünschten Wert für Warteschlangenlänge ein, und klicken Sie dann im Bereich Aktionen auf Anwenden.
Weitere Informationen zum Ändern der Eigenschaften im <limits-Element> des ASP-Elements> von IIS 7.0 <finden Sie unter ASP-Grenzwerte <> (https://go.microsoft.com/fwlink/?LinkId=157483).
Hinweis
Da diese Eigenschaft nur auf Serverebene angewendet werden kann, wirkt sich die Änderung dieser Eigenschaft auf alle Websites aus, die auf dem Server ausgeführt werden.
Hinweis
Die ASP Queue Length-Eigenschaft für IIS 7.0 ersetzt die ASP 6.0 AspRequestQueueMax ASP Metabase-Einstellung. Informationen zur ASP-Metabase-Einstellung für IIS 6.0 AspRequestQueueMax finden Sie unter Optimieren der ASP-Metabasiseinstellungen (https://go.microsoft.com/fwlink/?LinkId=158834) auf MSDN.
Optimieren des Registrierungseintrags MaxPoolThreads
Diese Einstellung gibt die Anzahl der Poolthreads an, die pro Prozessor erstellt werden sollen. Poolthreads watch das Netzwerk für Anforderungen und verarbeiten eingehende Anforderungen. Die MaxPoolThreads-Anzahl enthält keine Threads, die von ISAPI-Anwendungen verwendet werden. Im Allgemeinen sollten Sie nicht mehr als 20 Threads pro Prozessor erstellen. MaxPoolThreads ist ein REG_DWORD Registrierungseintrag unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\ mit dem Standardwert 4.
Deaktivieren der WCF-Dienstablaufverfolgung
Verwenden Sie das Konfigurations-Editor-Tool (SvcConfigEditor.exe), um die WCF-Dienstablaufverfolgung in einer Produktionsumgebung zu deaktivieren. Weitere Informationen zum Konfigurations-Editor-Tool finden Sie unter Configuration Editor Tool (SvcConfigEditor.exe) (https://go.microsoft.com/fwlink/?LinkID=127070).