Freigeben über

Allgemeine Optimierungen für BizTalk Server – Teil 2

  • 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.

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

Es sollten separate Hosts für das Senden, Empfangen, Verarbeiten und Nachverfolgen erstellt werden. 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 BizTalk-Server in einer BizTalk-Gruppe. Mit mehreren Hosts können Sie auch 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, während der eingehende Empfang von Nachrichten weiterhin erfolgen kann. Das Trennen von Hostinstanzen nach Funktionalität bietet auch die folgenden Vorteile:

  • Jeder Host instance verfügt über einen eigenen Satz von Ressourcen wie Arbeitsspeicher, Handles und Threads im .NET-Threadpool.

  • Mehrere BizTalk-Hosts reduzieren auch Konflikte in den Hostwarteschlangentabellen der Messagebox-Datenbank, 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. Auf diese Weise können Sie beispielsweise Host_A Zugriff auf FileShare_B gewähren, während keiner der anderen Hosts auf die Dateifreigabe zugreifen kann.

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" in der BizTalk Server Hilfe unter https://go.microsoft.com/fwlink/?LinkId=101588.

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 für die Nachverfolgung erstellt werden, wodurch die Auswirkungen der Nachverfolgung auf Hosts, die für die Nachrichtenverarbeitung vorgesehen sind, minimiert werden.

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 Nachverfolgungsdatendecodierungsdienst beendet wird, werden Nachverfolgungs-Interceptors 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" im BizTalk Server Hilfe unter https://go.microsoft.com/fwlink/?LinkId=101589. 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). Um eine optimale Leistung zu erzielen, 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 der BizTalk Server Hilfe:

  • "Verwalten des BAM-Ereignisbusdiensts" unter https://go.microsoft.com/fwlink/?LinkId=101590.

  • "Creating Instances of the BAM Event Bus Service" at https://go.microsoft.com/fwlink/?LinkId=101591.

Verwalten ASP.NET Threadnutzung oder gleichzeitiges Ausführen von Anforderungen für Webanwendungen, die Orchestrierungen hosten, die als Web- oder WCF-Dienst veröffentlicht wurden

Die Anzahl der Worker- und E/A-Threads (IIS 6.0 und IIS 7.0 im klassischen Modus) oder die Anzahl gleichzeitig ausgeführter Anforderungen (integrierter IIS 7.0-Modus) für eine ASP.NET Webanwendung, die eine als Webdienst veröffentlichte Orchestrierung hostet, sollte unter den folgenden Bedingungen geändert werden:

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

  • Der Wert der Leistungsindikatoren ASP.NET Apps v2.0.50727\Wartezeit anfordern oder ASP.NET Apps v2.0.50727\Anforderungsausführungszeit ist ungewöhnlich hoch.

  • Ein Fehler ähnlich dem folgenden, der im Anwendungsprotokoll des Computers generiert wird, auf dem die Webanwendung gehostet wird:

    Event Type: Warning
Event Source: W3SVC Event Category: None
Event ID: 1013
Date: 6/4/2009
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 Orchestrierungen unter IIS 6.0 und IIS 7.0 hosten, die im klassischen Modus ausgeführt werden

Wenn der AutoConfig-Wert in der machine.config-Datei eines IIS 6.0-Servers oder IIS 7.0-Servers, der im klassischen Modus ausgeführt wird, auf TRUE festgelegt ist, verwaltet ASP.NET 2.0 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-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 beim Senden von Webdienstanforderungen von ASP.NET Anwendungen" (https://go.microsoft.com/fwlink/?LinkID=66483).

Verwalten der Anzahl gleichzeitig ausgeführter Anforderungen für Webanwendungen, die Orchestrierungen in IIS 7.0 hosten, die im integrierten Modus ausgeführt werden

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 iis 7.0 im klassischen Modus. Wenn ASP.NET 2.0 in IIS 7.0 im integrierten Modus gehostet wird, beschränkt ASP.NET 2.0 die Anzahl gleichzeitig ausgeführter Anforderungen und nicht die 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 ASP.NET 2.0 unter IIS 7.0 im integrierten Modus ausgeführt wird, 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 maxConcurrentThreadsPerCPU angegebene Wert geändert wird. Der MaxConcurrentThreadsPerCPU-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 maxConcurrentThreadsPerCPU zu ändern, um die Anzahl gleichzeitig ausgeführter Anforderungen zu steuern:

Festlegen des MaxConcurrentThreadsPerCPU-Werts in der Registrierung

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

Warnung

Die Verwendung des Registrierungs-Editors erfolgt auf Ihr eigenes Risiko. Eine falsche Verwendung kann zu Problemen führen, bei denen Sie Ihr Betriebssystem neu installieren müssen. 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 Startmenü die Eingabeaufforderung Ausführen , und starten Sie sie , geben Sieregedit.exeein, und wählen Sie dann OK aus, 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ü Bearbeiten die Option Neu und dann Schlüssel aus.

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

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

    4. Schließen Sie den Registrierungs-Editor.

Festlegen des MaxConcurrentThreadsPerCPU-Werts 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. Dies ist erforderlich, 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 maxConcurrentThreadsPerCPU 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-Hostingthreadwerten 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 threadstarvation 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 nicht mehr Threads the.NET einem Host zugeordneten Threadpool zugewiesen werden, als erforderlich ist. 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.

Ändern Sie die Anzahl der im .NET-Threadpool, der einer Instanz eines BizTalk-Hosts zugeordnet ist, verfügbaren Windows-Threads, indem Sie die entsprechenden Werte für das CLR-Hosting in der Registrierung von BizTalk Server erstellen.

Warnung

Eine falsche Verwendung des Registrierungs-Editors kann zu Problemen führen, bei denen Sie Ihr Betriebssystem neu installieren müssen. Sie verwenden den Registrierungs-Editor auf eigene Gefahr. Weitere Informationen zum Sichern, Wiederherstellen und Ändern der Registrierung finden Sie im Microsoft Knowledge Base-Artikel "Beschreibung der Microsoft Windows-Registrierung" unter https://go.microsoft.com/fwlink/?LinkId=62729.

Hinweis

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

Führen Sie die folgenden Schritte aus, um die Anzahl der verfügbaren Threads im .NET-Threadpool zu ändern, der jedem instance eines BizTalk-Hosts zugeordnet ist:

  1. Beenden Sie den BizTalk-Host instance.

  2. Klicken Sie auf Start, klicken Sie auf Ausführen, geben Sieregedit.exeein, und klicken Sie dann auf OK , um den Registrierungs-Editor zu starten. Navigieren Sie zuHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$hostname, wobei hostname der Name des Hosts ist, der dem Host instance zugeordnet ist.

    Hinweis

    Wenn Sie Ihre BizTalk Server 2006-Installation von BizTalk Server 2004 aktualisiert haben, wird dieser Registrierungsschlüssel möglicherweise als HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvcGUID dargestellt, wobei guid eine GUID ist, die für jeden instance eines BizTalk Server Hosts eindeutig ist.

  3. Suchen Sie den CLR-Hostingschlüssel . Wenn dieser Schlüssel nicht vorhanden ist, erstellen Sie den Schlüssel, indem Sie die folgenden Schritte ausführen:

    1. Klicken Sie im Menü Bearbeiten auf Neu und dann auf Schlüssel.

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

  4. Erstellen Sie unter dem CLR-Hostingschlüssel die folgenden DWORD-Einträge mit den angegebenen Werten.

    DWORD-Eintrag Standardwert Empfohlener Wert
    MaxIOThreads 20 100
    Max.Arbeits-threads 25 100 Wichtig: Das Erhöhen dieses Werts über 100 kann sich negativ auf die Leistung des SQL Server Computers auswirken, auf dem die BizTalk Server MessageBox-Datenbank gehostet wird. Wenn dieses Problem auftritt, kann bei SQL Server eine Deadlockbedingung auftreten. Es wird empfohlen, dass dieser Parameter nicht über den Wert 100 hinaus erhöht wird.
    MinIOThreads 1 25
    MinWorkerThreads 1 25

    Hinweis

    Diese empfohlenen Werte sind für die meisten Szenarien ausreichend, müssen aber möglicherweise erhöht werden, je nachdem, wie viele Adapterhandler oder Orchestrierungen auf jedem Host instance ausgeführt werden.

    Hinweis

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

  5. Schließen Sie den Registrierungs-Editor.

  6. Starten Sie den BizTalk-Host instance neu.

Deaktivieren der Nachverfolgung für Orchestrierungen, Sendeports, Empfangsports und Pipelines, wenn keine Nachverfolgung erforderlich ist

Die Nachverfolgung verursacht einen Leistungsaufwand innerhalb BizTalk Server, da Daten in die MessageBox-Datenbank geschrieben und dann asynchron in die BizTalk-Nachverfolgungsdatenbank verschoben werden müssen. Wenn die Nachverfolgung keine geschäftliche Anforderung ist, deaktivieren Sie die Nachverfolgung, um den Mehraufwand zu reduzieren und die Leistung zu steigern. Weitere Informationen zum Konfigurieren der Nachverfolgung finden Sie unter "Konfigurieren der Nachverfolgung mithilfe der BizTalk Server-Verwaltungskonsole" in der BizTalk Server Hilfe unter https://go.microsoft.com/fwlink/?LinkID=106742.

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 Archivauftrags in der BizTalk Server Hilfe unter https://go.microsoft.com/fwlink/?LinkID=104908.

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.

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

Während BizTalk Server 2006 und nachfolgenden Versionen von BizTalk Server ihnen ermöglichen, 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. Dadurch wird jedoch ein Single Point of Failure eingeführt, 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.

Leistungsoptimierungen in der BizTalk Server-Dokumentation

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