Allgemeine Optimierungen für BizTalk Server – Teil 1

  • Artikel

Die folgenden Empfehlungen können verwendet werden, um die Leistung BizTalk Server zu erhöhen. Die in diesem Thema aufgeführten Optimierungen werden angewendet, nachdem BizTalk Server installiert und konfiguriert wurde.

Konfigurieren von MSDTC

Um Transaktionen zwischen SQL Server und BizTalk Server zu erleichtern, müssen Sie Microsoft Distributed Transaction Coordinator (MS DTC) aktivieren. Informationen zum Konfigurieren von MSDTC auf BizTalk Server finden Sie im Thema Allgemeine Richtlinien zur Verbesserung der Betriebssystemleistung.

Empfehlungen zum Konfigurieren BizTalk Server Hosts

Dieser Abschnitt enthält Empfehlungen zum Konfigurieren BizTalk Server Hosts.

Erstellen mehrerer BizTalk Server Hosts und separate Hostinstanzen nach Funktionalität

Befolgen Sie die folgenden Richtlinien, um mehrere BizTalk Server Hosts zu erstellen und Workloads diesen Hosts zuzuordnen:

  • Erstellen Sie separate Hosts für das Senden, Empfangen, Verarbeiten und Nachverfolgen von Funktionen. Das Erstellen mehrerer BizTalk-Hosts bietet Flexibilität beim Konfigurieren der Workload in Ihrer BizTalk-Gruppe und ist das primäre Mittel zur Verteilung der Verarbeitung auf die Computer, auf denen BizTalk Server in einer BizTalk-Gruppe ausgeführt werden. Wenn Sie mehrere Hosts verwenden, können Sie einen Host beenden, ohne dass sich dies auf andere Hosts auswirkt. Beispielsweise können Sie das Senden von Nachrichten beenden, damit sie in der MessageBox-Datenbank in die Warteschlange eingereiht werden können, während ein Empfangsadapter, der auf einem anderen Host ausgeführt wird, instance, eingehende Nachrichten empfangen kann. Das Trennen von Hostinstanzen nach Funktionalität bietet auch die folgenden Vorteile:

    • Wenn Sie mehrere BizTalk-Hosts ausführen, werden Konflikte in den Warteschlangentabellen der MessageBox-Datenbankhosts reduziert, da jedem Host eigene Arbeitswarteschlangentabellen in der MessageBox-Datenbank zugewiesen sind.

    • Die Drosselung wird in BizTalk Server auf Hostebene implementiert. Dadurch können Sie für jeden Host unterschiedliche Drosselungsmerkmale festlegen.

    • Die Sicherheit wird auf Hostebene implementiert; Jeder Host wird unter einer separaten Windows-Identität ausgeführt. Dadurch können Sie z. B. Host_A Zugriff auf FileShare_B gewähren, während keiner der anderen Hosts auf die Dateifreigabe zugreifen kann.

  • Jeder Host instance verfügt über einen eigenen Satz von Ressourcen wie Arbeitsspeicher, Handles und Threads im .NET-Threadpool. Erwägen Sie beim Zuweisen von Arbeitsauslastungen über Hosts hinweg das Platzieren von Ressourcen, die zusammenskaliert werden, auf demselben Host.

  • Separate Adapter und Orchestrierungen, die unterschiedliche Prioritäten für Ressourcen auf verschiedenen Hosts haben. Diese Technik unterstützt die Platzierung von Hosts, die Anwendungen mit hoher Priorität auf dedizierten BizTalk Server Computern ausführen.

Hinweis

Das Erstellen zusätzlicher Hostinstanzen bietet zwar Vorteile, aber es gibt auch potenzielle Nachteile, wenn zu viele Hostinstanzen erstellt werden. Jeder Host instance ist ein Windows-Dienst (BTSNTSvc.exe), der zusätzliche Last für die MessageBox-Datenbank generiert und Computerressourcen (z. B. CPU, Arbeitsspeicher, Threads) nutzt.

Weitere Informationen zum Ändern BizTalk Server Hosteigenschaften finden Sie unter Ändern von Hosteigenschaften (https://go.microsoft.com/fwlink/?LinkID=154359) in der hilfe zu BizTalk Server 2010.

Konfigurieren eines dedizierten Nachverfolgungshosts

BizTalk Server ist für den Durchsatz optimiert, sodass die Standard-Orchestrierungs- und Messaging-Engines Nachrichten nicht direkt in die BizTalk-Nachverfolgungs- oder BAM-Datenbanken verschieben, da dies diese Engines von ihrer primären Aufgabe der Ausführung von Geschäftsprozessen ablenken würde. Stattdessen belässt BizTalk Server die Nachrichten in der MessageBox-Datenbank und markiert sie als erfordern eine Verschiebung in die BizTalk-Nachverfolgungsdatenbank. Ein Hintergrundprozess (der Nachverfolgungshost) verschiebt die Nachrichten dann in die BizTalk-Nachverfolgungs- und BAM-Datenbanken. Da die Nachverfolgung ein ressourcenintensiver Vorgang ist, sollte ein separater Host erstellt werden, der für die Nachverfolgung reserviert ist, wodurch die Auswirkungen der Nachverfolgung auf Hosts, die für die Nachrichtenverarbeitung vorgesehen sind, minimiert werden. Für eine optimale Leistung sollte mindestens ein Nachverfolgungshost instance pro MessageBox-Datenbank vorhanden sein. Die tatsächliche Anzahl der Nachverfolgungshostinstanzen sollte N + 1 sein, wobei N die Anzahl der MessageBox-Datenbanken ist. "+1" dient zur Redundanz, falls auf einem der Computer, auf dem die Nachverfolgung gehostet wird, ein Fehler auftritt.

Mit einem dedizierten Nachverfolgungshost können Sie auch andere BizTalk-Hosts beenden, ohne BizTalk Server Nachverfolgung zu beeinträchtigen. Die Verschiebung von Nachverfolgungsdaten aus der MessageBox-Datenbank ist für eine fehlerfreie BizTalk Server System von entscheidender Bedeutung. Wenn der BizTalk-Host, der für das Verschieben von Nachverfolgungsdaten in der BizTalk-Gruppe verantwortlich ist, beendet wird, wird der Dienst Für die Nachverfolgungsdatendecodierung nicht ausgeführt. Dies hat folgende Auswirkungen:

  • HAT-Nachverfolgungsdaten werden nicht aus der MessageBox-Datenbank in die BizTalk-Nachverfolgungsdatenbank verschoben.

  • BAM-Nachverfolgungsdaten werden nicht aus der MessageBox-Datenbank in die primäre BAM-Importdatenbank verschoben.

  • Da Daten nicht verschoben werden, können sie nicht aus der MessageBox-Datenbank gelöscht werden.

  • Wenn der Dienst für die Nachverfolgungsdatendecodierung beendet wird, werden Überwachungsinterfängoren weiterhin ausgelöst und Nachverfolgungsdaten in die MessageBox-Datenbank geschrieben. Wenn die Daten nicht verschoben werden, führt dies dazu, dass die MessageBox-Datenbank aufgebläht wird, was sich im Laufe der Zeit auf die Leistung auswirkt. Auch wenn benutzerdefinierte Eigenschaften nicht nachverfolgt oder BAM-Profile nicht eingerichtet sind, werden standardmäßig einige Daten nachverfolgt (z. B. Empfangen/Senden von Pipelineereignissen und Orchestrierungsereignisse). Wenn Sie den Nachverfolgungsdatendecodierungsdienst nicht ausführen möchten, deaktivieren Sie die gesamte Nachverfolgung, damit keine Interceptors Daten in der Datenbank speichern. Informationen zum Deaktivieren der globalen Nachverfolgung finden Sie unter Deaktivieren der globalen Nachverfolgung (https://go.microsoft.com/fwlink/?LinkID=154193) in BizTalk Server 2010-Hilfe. Verwenden Sie die BizTalk Server-Verwaltungskonsole, um Nachverfolgungsereignisse selektiv zu deaktivieren.

    Der Nachverfolgungshost sollte auf mindestens zwei Computern ausgeführt werden, auf denen BizTalk Server ausgeführt wird (für Redundanz bei einem Fehler). Für eine optimale Leistung sollten Sie mindestens über einen Nachverfolgungshost instance pro MessageBox-Datenbank verfügen. Die tatsächliche Anzahl der Nachverfolgungshostinstanzen sollte (N + 1) sein, wobei N die Anzahl der MessageBox-Datenbanken ist. "+1" dient zur Redundanz, falls auf einem der Computer, auf dem die Nachverfolgung gehostet wird, ein Fehler auftritt.

    Ein Nachverfolgungshost instance die Nachverfolgungsdaten für bestimmte MessageBox-Datenbanken verschiebt, aber es gibt nie mehr als einen Nachverfolgungshost instance Verschieben von Daten für eine bestimmte MessageBox-Datenbank. Wenn Sie beispielsweise über drei MessageBox-Datenbanken und nur über zwei Nachverfolgungshostinstanzen verfügen, muss eine der Hostinstanzen Daten für zwei der MessageBox-Datenbanken verschieben. Durch das Hinzufügen eines dritten Nachverfolgungshosts instance wird die Arbeit des Überwachungshosts auf einen anderen Computer verteilt, auf dem BizTalk Server ausgeführt wird. In diesem Szenario würde das Hinzufügen eines vierten Nachverfolgungshosts instance keine weitere Nachverfolgungshostarbeit verteilen, sondern einen zusätzlichen Nachverfolgungshost instance für die Fehlertoleranz bereitstellen.

    Weitere Informationen zum BAM Event Bus-Dienst finden Sie in den folgenden Themen in BizTalk Server 2010-Hilfe:

  • Verwalten des BAM-Ereignisbusdiensts (https://go.microsoft.com/fwlink/?LinkID=154194).

  • Erstellen von Instanzen des BAM-Ereignisbusdiensts (https://go.microsoft.com/fwlink/?LinkID=154195).

Clustern Sie BizTalk-Hosts nicht, es sei denn, dies ist absolut erforderlich.

Während BizTalk Server 2010 ihnen ermöglicht, einen BizTalk-Host als Clusterressource zu konfigurieren, sollten Sie dies nur in Betracht ziehen, wenn Sie Hochverfügbarkeit für eine Ressource bereitstellen müssen, die nicht auf mehreren BizTalk-Computern gehostet werden kann. Beispielsweise sollten sich Ports, die den FTP-Adapter verwenden, nur auf einem Host instance befinden, da das FTP-Protokoll keine Dateisperrung ermöglicht. Dies führt jedoch zu einem Single Point of Failure, der vom Clustering profitieren würde. Hosts, die Adapter enthalten, z. B. Datei-, SQL-, HTTP- oder Verarbeitungshosts, können intern einen Lastenausgleich zwischen Computern aufweisen und nicht vom Clustering profitieren.

Erhöhen Sie die anzahl der zulässigen gleichzeitigen HTTP-Verbindungen, indem Sie den Wert für den maxconnection-Parameter ändern.

Standardmäßig öffnen die HTTP-Adapter (einschließlich WCF-basierter HTTP-Adapter) nur zwei gleichzeitige HTTP-Verbindungen von jedem Computer, auf dem BizTalk Server ausgeführt wird, mit einem bestimmten Zielserver.

Diese Einstellung entspricht dem IETF RFC für die HTTP 1.1-Spezifikation und ist zwar für Benutzerszenarien geeignet, aber nicht für hohen Durchsatz optimiert. Die Einstellung drosselt ausgehende HTTP-Aufrufe an jeden Server auf zwei gleichzeitige Senden von jedem Computer, auf dem BizTalk Server ausgeführt wird.

Um die Anzahl gleichzeitiger Verbindungen zu erhöhen, können Sie den Wert für den maxconnection-Parameter in der BizTalk Server-Konfigurationsdatei ändern, BTSNTSvc.exe.config (oder BTSNTSvc64.exe.config für 64-Bit-Hosts) auf jedem BizTalk Server. Sie können dies für die spezifischen Server erhöhen, die aufgerufen werden. Als Faustregel sollte der Wert für den maxconnection-Parameter auf 12 * die Anzahl der CPUs oder Kerne auf dem Computer festgelegt werden, auf dem die Webanwendung gehostet wird.

Hinweis

Erhöhen Sie den Wert für den parameter maxconnection nicht auf einen so großen Wert, dass der aufgerufene Webserver mit HTTP-Verbindungen überlastet ist. Nachdem Sie den Wert für den maxconnection-Parameter geändert haben, führen Sie Stresstests durch, indem Sie Anforderungen an jeden Zielwebserver senden, um einen Wert für maxconnection zu ermitteln, der eine gute Leistung und HTTP-Sendevorgänge bietet, ohne die Zielwebserver zu überlasten.

Es folgt ein Beispiel der Konfiguration der Eigenschaft für die maximale Anzahl von Verbindungen:

<configuration>
  <system.net>
    <connectionManagement>
      <add address="http://www.contoso.com" maxconnection="24" />
      <add address="*" maxconnection="48" />
    </connectionManagement>
  </system.net>
</configuration>

Beim Festlegen der maxconnection-Eigenschaft können HTTP, HTTPS, die IP-Adresse der Website und die Portnummer angegeben werden. Weitere Beispiele:

<add address="http://www.contoso.com" maxconnection="24" />
<add address="http://www.contoso.com:8080" maxconnection="24" />
<add address="http://<IP-address>" maxconnection="24" />

Weitere Informationen zum Optimieren von IIS und ASP.NET Einstellungen für Webdienste finden Sie im Abschnitt "ASP.NET Einstellungen, die sich auf die Leistung des HTTP-Adapters auswirken können" unter Konfigurationsparameter, die sich auf die Adapterleistung auswirken (https://go.microsoft.com/fwlink/?LinkID=154200) in BizTalk Server 2010-Hilfe.

Verwalten ASP.NET Threadnutzung oder gleichzeitiges Ausführen von Anforderungen für Webanwendungen, die isolierte empfangene Standorte, Back-End-Webdienste und WCF-Dienste hosten können

Die Anzahl der Worker- und E/A-Threads (IIS 7.5 und IIS 7.0 im klassischen Modus) oder die Anzahl gleichzeitig ausgeführter Anforderungen (integrierter IIS 7.5- und 7.0-Modus) für eine ASP.NET Webanwendung, die isolierte empfangene Speicherorte hostet, Back-End-Webdienste und WCF-Dienste sollten unter den folgenden Bedingungen geändert werden:

  • Die CPU-Auslastung ist kein Engpass auf dem Hostwebserver.

  • Der Wert von:

    • ASP.NET Apps v4.0.30319 \Wartezeit anfordern oder ASP.NET Apps v4.0.30319 \Leistungsindikatoren für die Anforderungsausführungszeit sind ungewöhnlich hoch.

    • ASP.NET Apps v2.0.50727\Anforderungswartezeit oder ASP.NET Apps v2.0.50727\Leistungsindikatoren für die Anforderungsausführungszeit sind ungewöhnlich hoch.

  • Im Anwendungsprotokoll des Computers, der die Webanwendung hostet, wird ein Fehler ähnlich dem folgenden generiert.

    Event Type: Warning
Event Source: W3SVC Event Category: None
Event ID: 1013
Date: 11/4/2010
Time: 1:03:47 PM
User: N/A
Computer: <ComputerName>
Description: A process serving application pool 'DefaultAppPool' exceeded time limits during shut down. The process id was '<xxxx>'

Verwalten ASP.NET Threadnutzung für Webanwendungen, die isolierte empfangene Speicherorte, Back-End-Webdienste und WCF-Dienste unter IIS 7.5 und IIS 7.0 hosten können, die im klassischen Modus ausgeführt werden

Wenn der AutoConfig-Wert in der machine.config-Datei eines IIS 7.5- und IIS 7.0-Servers, auf dem im klassischen Modus ausgeführt wird, auf TRUE festgelegt ist, verwaltet ASP.NET 2.0 und ASP.NET 4 die Anzahl der Workerthreads und E/A-Threads, die allen zugeordneten IIS-Arbeitsprozessen zugeordnet sind.

<processModel autoConfig="true" />

Um die Anzahl der Worker- und E/A-Threads für eine ASP.NET 2.0- und ASP.Net 4-Webanwendung manuell zu ändern, öffnen Sie die zugeordnete machine.config-Datei, und geben Sie dann neue Werte für die Parameter maxWorkerThreads und maxIoThreads ein .

<!-- <processModel autoConfig="true" /> -->
    <processModel maxWorkerThreads="200" maxIoThreads="200" />

Hinweis

Diese Werte dienen nur zur Orientierung; Stellen Sie sicher, dass Sie Änderungen an diesen Parametern testen.

Weitere Informationen zu Optimierungsparametern in der machine.config-Datei für eine ASP.NET 2.0-Webanwendung finden Sie im Microsoft Knowledge Base-Artikel 821268 Konflikte, schlechte Leistung und Deadlocks, wenn Sie Webdienstanforderungen von ASP.NET Anwendungen (https://go.microsoft.com/fwlink/?LinkID=144169) stellen.

Verwalten der Anzahl gleichzeitig ausgeführter Anforderungen für ASP.NET 2.0-Webanwendungen, die isolierte empfangene Speicherorte, Back-End-Webdienste und WCF-Dienste unter IIS 7.5 und IIS 7.0 hosten können, die im integrierten Modus ausgeführt werden

Wenn ASP.NET 2.0 in IIS 7.5 und IIS 7.0 im integrierten Modus gehostet wird, wird die Verwendung von Threads anders behandelt als bei IIS 7.5 und IIS 7.0 im klassischen Modus. Wenn ASP.NET 2.0 in IIS 7.5 und IIS 7.0 im integrierten Modus gehostet wird, beschränkt ASP.NET 2.0 die Anzahl gleichzeitig ausgeführter Anforderungen anstelle der Anzahl der Threads , die gleichzeitig Anforderungen ausführen. Bei synchronen Szenarien wird dadurch indirekt die Anzahl der Threads eingeschränkt, aber bei asynchronen Szenarien ist die Anzahl der Anforderungen und Threads wahrscheinlich sehr unterschiedlich. Wenn sie ASP.NET 2.0 unter IIS 7.5 und IIS 7.0 im integrierten Modus ausführen, werden die Parameter maxWorkerThreads und maxIoThreads in der datei machine.config nicht verwendet, um die Anzahl der ausgeführten Threads zu steuern. Stattdessen kann die Anzahl gleichzeitig ausgeführter Anforderungen vom Standardwert 12 pro CPU geändert werden, indem der für maxConcurrentRequestsPerCPU angegebene Wert geändert wird. Der MaxConcurrentRequestsPerCPU-Wert kann entweder in der Anforderung oder im Konfigurationsabschnitt einer aspnet.config-Datei angegeben werden. Führen Sie die folgenden Schritte aus, um den Standardwert für maxConcurrentRequestsPerCPU zu ändern, um die Anzahl gleichzeitig ausgeführter Anforderungen zu steuern:

Festlegen des Werts maxConcurrentRequestsPerCPU in der Registrierung

Diese Einstellung ist global und kann nicht für einzelne Anwendungspools oder Anwendungen geändert werden.

Warnung

Die Verwendung des Registrierungs-Editors erfolgt auf Ihr eigenes Risiko. Eine falsche Verwendung kann Zu Problemen führen, die eine Neuinstallation des Betriebssystems erfordern. Weitere Informationen zum Sichern, Wiederherstellen und Ändern der Registrierung finden Sie im Microsoft Knowledge Base-Artikel 256986 – Windows-Registrierungsinformationen für fortgeschrittene Benutzer.

  1. Suchen Sie im Menü Start nach der Eingabeaufforderung Ausführen , und starten Sie sie, geben Sie regedit.exeein, und klicken Sie dann auf OK , um den Registrierungs-Editor zu starten.

  2. Navigieren Sie zu HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0

  3. Erstellen Sie den Schlüssel, indem Sie die folgenden Schritte ausführen:

    1. Wählen Sie im Menü Bearbeitendie Option Neu und dann Schlüssel aus.

    2. Geben Sie maxConcurrentRequestsPerCPU ein, und drücken Sie dann die EINGABETASTE.

    3. Erstellen Sie unter dem Schlüssel maxConcurrentRequestsPerCPU einen DWORD-Eintrag mit dem neuen Wert für maxConcurrentRequestsPerCPU.

    4. Schließen Sie den Registrierungs-Editor.

Festlegen des Werts maxConcurrentRequestsPerCPU für einen Anwendungspool im Konfigurationsabschnitt einer aspnet.config-Datei

  1. Laden Sie Microsoft .NET Framework 3.5 Service Pack 1 herunter, und installieren Sie es, was erforderlich ist, um die folgenden Werte in der Konfigurationsdatei festzulegen. Die Vollversion ist ebenfalls verfügbar.

  2. Öffnen Sie die aspnet.config-Datei für den Anwendungspool.

  3. Geben Sie die neuen Werte für die Parameter maxConcurrentRequestsPerCPU und requestQueueLimit ein.

    <system.web>
    <applicationPool maxConcurrentRequestsPerCPU="12" requestQueueLimit="5000"/>
</system.web>

    Hinweis

    Dieser Wert überschreibt den für maxConcurrentRequestsPerCPU in der Registrierung angegebenen Wert. Die Einstellung requestQueueLimit ist identisch mit processModel/requestQueueLimit, mit der Ausnahme, dass die Einstellung in der aspnet.config-Datei die Einstellung in der machine.config-Datei überschreibt.

Weitere Informationen zum Konfigurieren ASP.NET Threadnutzung in IIS 7.0 finden Sie im Blog von Thomas Marquardt zur ASP.NET Threadverwendung in IIS 7.0 (https://go.microsoft.com/fwlink/?LinkId=157518).

Verwalten der Anzahl gleichzeitig ausgeführter Anforderungen für ASP.NET 4 Webanwendungen, die isolierte empfangene Speicherorte, Back-End-Webdienste und WCF-Dienste unter IIS 7.5 und 7.0 hosten können, die im integrierten Modus ausgeführt werden

Bei .NET Framework 4 ist die Standardeinstellung für maxConcurrentRequestsPerCPU 5000. Dies ist eine sehr große Zahl, sodass viele asynchrone Anforderungen gleichzeitig ausgeführt werden können. Weitere Informationen finden Sie unter <applicationPool-Element> (Webeinstellungen) (https://go.microsoft.com/fwlink/?LinkID=205339).

Im integrierten Modus für IIS 7.5 und IIS 7.0 bestimmt ein DWORD mit dem Namen MaxConcurrentRequestsPerCPU in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0 die Anzahl gleichzeitiger Anforderungen pro CPU. Standardmäßig ist der Registrierungsschlüssel nicht vorhanden, und die Anzahl der Anforderungen pro CPU ist auf 5000 begrenzt.

Festlegen des Werts maxConcurrentRequestsPerCPU in der Registrierung

Diese Einstellung ist global und kann nicht für einzelne Anwendungspools oder Anwendungen geändert werden.

Warnung

Die Verwendung des Registrierungs-Editors erfolgt auf Ihr eigenes Risiko. Eine falsche Verwendung kann Zu Problemen führen, die eine Neuinstallation des Betriebssystems erfordern. Weitere Informationen zum Sichern, Wiederherstellen und Ändern der Registrierung finden Sie im Microsoft Knowledge Base-Artikel 256986 – Windows-Registrierungsinformationen für fortgeschrittene Benutzer.

  1. Suchen Sie im Menü Start nach der Eingabeaufforderung Ausführen , und starten Sie sie, geben Sie regedit.exeein, und klicken Sie dann auf OK , um den Registrierungs-Editor zu starten.

  2. Navigieren Sie zu HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0.

  3. Erstellen Sie den Schlüssel, indem Sie die folgenden Schritte ausführen:

    1. Wählen Sie im Menü Bearbeitendie Option Neu und dann Schlüssel aus.

    2. Geben Sie maxConcurrentRequestsPerCPU ein, und drücken Sie dann die EINGABETASTE.

    3. Erstellen Sie unter dem Schlüssel maxConcurrentRequestsPerCPU einen DWORD-Eintrag mit dem neuen Wert für maxConcurrentRequestsPerCPU.

    4. Schließen Sie den Registrierungs-Editor.

Festlegen des Werts maxConcurrentRequestsPerCPU für einen Anwendungspool im Konfigurationsabschnitt einer aspnet.config-Datei

  1. Laden Sie Microsoft .NET Framework 4 herunter, und installieren Sie es, die zum Festlegen der folgenden Werte in der Konfigurationsdatei erforderlich ist.

  2. Öffnen Sie die aspnet.config-Datei für den Anwendungspool.

  3. Geben Sie neue Werte für die Parameter maxConcurrentRequestsPerCPU und requestQueueLimit ein.

    Die Werte im folgenden Beispiel sind die Standardwerte.

    <system.web>
    <applicationPool maxConcurrentRequestsPerCPU="5000" requestQueueLimit="5000"/>
</system.web>

    Hinweis

    Dieser Wert überschreibt den für maxConcurrentRequestsPerCPU in der Registrierung angegebenen Wert. Die Einstellung requestQueueLimit ist identisch mit processModel/requestQueueLimit, mit der Ausnahme, dass die Einstellung in der aspnet.config-Datei die Einstellung in der machine.config-Datei überschreibt.

Definieren von CLR-Hostthreadwerten für BizTalk-Hostinstanzen

Da ein Windows-Thread die grundlegendste ausführbare Einheit darstellt, die für einen Windows-Prozess zur Verfügung steht, ist es wichtig, ausreichend Threads für den .NET-Threadpool zu reservieren, der einer Instanz eines BizTalk-Hosts zugeordnet ist, um zu verhindern, dass Threads nicht mehr auf die CPU zugreifen können. Wenn ein Threadmangel auftritt, sind nicht genügend Threads verfügbar, um die angeforderte Arbeit auszuführen, die sich negativ auf die Leistung auswirkt. Gleichzeitig sollte darauf geachtet werden, dass the.NET einem Host zugeordneten Threadpools nicht mehr Threads zugewiesen werden, als erforderlich sind. Die Zuordnung von zu vielen Threads zum .NET-Threadpool, der einem Host zugeordnet ist, kann den Kontextwechsel erhöhen. Der Kontextwechsel tritt auf, wenn der Windows-Kernel von der Ausführung eines Threads zu einem anderen Thread wechselt, was zu Leistungskosten führt. Eine übermäßige Threadzuordnung kann zu übermäßigem Kontextwechsel führen, was sich negativ auf die Gesamtleistung auswirkt. Die Standardanzahl von Threads, die einem BizTalk-Host instance.NET-Threadpool zugeordnet sind, hängt davon ab, welche Version des .NET Framework installiert ist. Die .NET Framework 4 und der .NET Framework 3.5 SP1 haben die Standardwerte erheblich erhöht, was zu einer übermäßigen Threadzuordnung auf den BizTalk Server Computern und übermäßigen Sperrenkonflikten in der MessageBox-Datenbank führen kann.

Mithilfe des BizTalk-Einstellungsdashboards können Sie den Standardwert für die Anzahl von Windows-Threads ändern, die im .NET-Threadpool verfügbar sind, der einem instance eines BizTalk-Hosts zugeordnet ist. Weitere Informationen zum Ändern von .NET CLR-Einstellungen finden Sie unter Ändern von .NET CLR-Einstellungen (https://go.microsoft.com/fwlink/?LinkID=205344). .NET CLR-Einstellungen gelten pro zentraler CPU.

Hinweis

Workerthreads werden verwendet, um Arbeitselemente in der Warteschlange zu verarbeiten, und E/A-Threads sind dedizierte Rückrufthreads, die einem E/A-Vervollständigungsport zugeordnet sind, um eine abgeschlossene asynchrone E/A-Anforderung zu verarbeiten.

Threadingeinstellungen Standardwert Empfohlener Wert
Maximale E/A-Threads 250 250
Maximale Anzahl von Workerthreads 25 100 Wichtig: Das Erhöhen dieses Werts über 100 kann sich negativ auf die Leistung des SQL Server Computers auswirken, der die BizTalk Server MessageBox-Datenbank hostt. Wenn dieses Problem auftritt, kann bei SQL Server eine Deadlockbedingung auftreten. Es wird empfohlen, diesen Parameter nicht über den Wert 100 hinaus zu erhöhen.
Minimale E/A-Threads 25 25
Mindestarbeitsthreads 5 25

Hinweis

Die empfohlenen Werte sind keine absoluten Werte und müssen möglicherweise abhängig von der BizTalk-Anwendung angepasst werden. Ändern Sie jeweils einen Parameter, und messen Sie dann die Auswirkungen auf die Leistung und Stabilität der BizTalk-Plattform, bevor Sie zusätzliche Änderungen vornehmen.

Hinweis

Diese Werte werden implizit mit der Anzahl der Prozessoren auf dem Server multipliziert. Wenn Sie beispielsweise den Eintrag MaxWorkerThreads auf den Wert 100 festlegen, wird auf einem 4 CPU-Server effektiv der Wert 400 festgelegt.

Deaktivieren BizTalk Server Nachverfolgung auf Gruppenebene

Bei der Nachverfolgung entsteht Leistungsaufwand innerhalb BizTalk Server, da Daten in die MessageBox-Datenbank geschrieben und dann asynchron in die BizTalk-Nachverfolgungsdatenbank verschoben werden müssen. Die folgenden Überlegungen gelten beim Konfigurieren der Nachverfolgung in einer Produktions- BizTalk Server-Umgebung:

  • Als Faustregel gilt: Wenn die Nachverfolgung keine geschäftliche Anforderung ist, deaktivieren Sie die Nachverfolgung auf Gruppenebene, um den Mehraufwand zu reduzieren und die Leistung zu erhöhen.

    Führen Sie die folgenden Schritte aus, um BizTalk Server Nachverfolgung auf Gruppenebene zu deaktivieren:

    1. Erweitern Sie in der BizTalk Server VerwaltungskonsoleBizTalk Server Verwaltung, klicken Sie mit der rechten Maustaste auf BizTalk-Gruppe, und klicken Sie dann auf Einstellungen.

    2. Deaktivieren Sie im Dialogfeld BizTalk-Einstellungendashboard auf der Seite Gruppe das Kontrollkästchen Nachverfolgung auf Gruppenebene aktivieren .

    3. Klicken Sie auf OK , um die Änderungen anzuwenden, und beenden Sie das Dashboard Einstellungen.

  • Verwenden Sie die Nachrichtentextnachverfolgung nur bei Bedarf. Abhängig vom Nachrichtendurchsatz und der Nachrichtengröße kann die Nachverfolgung des Nachrichtentexts zu erheblichem Mehraufwand führen. Die BizTalk-Aktivitätsnachverfolgung bietet zwar offensichtliche Vorteile für das Debuggen und die Überwachung, hat aber auch erhebliche Auswirkungen auf Leistung und Skalierbarkeit. Daher sollten Sie nur Daten nachverfolgen, die aus Debug- und Sicherheitsgründen unbedingt erforderlich sind, und vermeiden Sie die Nachverfolgung redundanter Informationen.

  • Standardmäßig sind die folgenden Nachverfolgungsoptionen für Orchestrierungen aktiviert:

    • Orchestrierungsstart und -ende

    • Senden und Empfangen von Nachrichten

    • Shape-Anfang und -Ende

      Die Orchestrierungsnachverfolgungsoption "Shape start and end" verursacht einen erheblichen Mehraufwand und sollte in einer Produktionsumgebung, in der ein hoher Durchsatz erforderlich ist, nicht aktiviert werden. Auf die Optionen für die Orchestrierungsnachverfolgung kann in der BizTalk-Verwaltungskonsole auf der Seite Nachverfolgung des Dialogfelds Orchestrierungseigenschaften zugegriffen werden.

    Weitere Informationen zum Konfigurieren der Nachverfolgung finden Sie unter Konfigurieren der Nachverfolgung mithilfe der BizTalk Server-Verwaltungskonsole (https://go.microsoft.com/fwlink/?LinkId=158021).

Verringern des Löschzeitraums für den DTA-Bereinigungs- und Archivierungsauftrag von 7 Tagen auf 2 Tage in Szenarien mit hohem Durchsatz

Standardmäßig ist das Löschintervall für die Nachverfolgung von Daten in BizTalk Server auf 7 Tage festgelegt. In einem Szenario mit hohem Durchsatz kann dies zu einem übermäßigen Aufbau von Daten in der Nachverfolgungsdatenbank führen, was sich letztendlich auf die Leistung der MessageBox auswirkt und sich wiederum negativ auf den Nachrichtenverarbeitungsdurchsatz auswirkt.

Reduzieren Sie in Szenarien mit hohem Durchsatz das Intervall für die harte und weiche Bereinigung von der Standardeinstellung von 7 Tagen auf 2 Tage. Weitere Informationen zum Konfigurieren des Löschintervalls finden Sie unter Konfigurieren des DTA-Bereinigungs- und Archivierungsauftrags (https://go.microsoft.com/fwlink/?LinkID=153814) in der Hilfe zu BizTalk Server 2010.

Konfigurieren des %temp%-Pfads für das BizTalk Service-Konto so, dass er auf einen separaten Datenträger oder eine LUN verweist

Dies sollte erfolgen, da BizTalk den temporären Speicherort verwendet, um Dateien auf den Datenträger zu streamen, wenn komplexe Zuordnungsvorgänge ausgeführt werden.

Installieren der neuesten Service Packs

Die neuesten Service Packs für BizTalk Server und die .NET Framework sollten installiert werden, da diese Korrekturen enthalten, die möglicherweise auftretende Leistungsprobleme beheben können.

Leistungsoptimierungen in der BizTalk Server-Dokumentation

Wenden Sie die folgenden Empfehlungen aus der BizTalk Server-Dokumentation entsprechend an:

Weitere Informationen

Optimieren der Leistung von BizTalk Server