Überlegungen zu Nachrichten
BizTalk Server bietet umfangreiche Funktionen zum Senden, Empfangen, Transformieren und Verarbeiten von Nachrichten. Diese Funktionen umfassen unter anderem:
Möglichkeit zum Senden und Empfangen von Nachrichten mit mehreren Branchenstandardtransporten wie HTTP, SMTP, FTP/FTPS und WCF. Die Unterstützung auf Transportebene für das Senden und Empfangen von Nachrichten erfolgt mithilfe BizTalk Server Adaptern. Die Integration von BizTalk Server Nachrichtenverarbeitung in verschiedene Branchenanwendungen (LOB) erfolgt mithilfe eines von vielen verfügbaren BizTalk Server Accelerators oder Adaptern, z. B. bizTalk Accelerator für HIPAA, BizTalk Accelerator für SWIFT oder bizTalk SAP-Adapter. Diese Beschleuniger und Adapter entsprechen den Branchenstandards, was wiederum eine einfache Integration von BizTalk Server mit Systemen bietet, die den jeweiligen Branchenstandards entsprechen.
Möglichkeit, mehrere Nachrichtenformate wie Nur-Text, XML, Binärformat und andere zu verarbeiten. Diese Funktionalität ist entscheidend für die Integration von BizTalk Server mit einem breiten Spektrum von Handelspartnern.
Unterstützung für Nachrichtentransformation oder Dokumentzuordnung. Die Zuordnung berücksichtigt die Transformation von Daten zwischen verschiedenen Schemas. Beispielsweise könnte die Zuordnung verwendet werden, um den Inhalt einer empfangenen Kundenbestellung in einen Beleg mit Versandbenachrichtigung zu transformieren, der an den Kunden zurückgesendet werden soll.
BizTalk Server Orchestrierungen bieten Funktionen zum Erstellen von Geschäftsprozessen, die sich über Zeit, Organisationen, Anwendungen und Personen erstrecken. BizTalk Server stellt die Orchestrierung Designer grafische Schnittstelle bereit, um Geschäftsprozesse zu entwickeln, die Unterstützung für Transaktionen (sowohl herkömmlicher "atomarer" MSDTC-Typ als auch lange Ausführung), Ausnahmebehandlung, Debuggen, Nachverfolgung und Erweiterbarkeit für das Aufrufen von externem Code umfassen.
Hinweis
Anleitungen zu bewährten Methoden für die Verwendung von Orchestrierungen in BizTalk Server finden Sie unter Optimieren der Orchestrierungsleistung. Ausführliche Informationen zur Verwendung von Orchestrierung Designer finden Sie im Thema Erstellen von Orchestrierungen mithilfe der Designer (https://go.microsoft.com/fwlink/?LinkId=158997) in der BizTalk Server-Dokumentation.
Im weiteren Verlauf dieses Themas werden Leistungsüberlegungen im Zusammenhang mit der Größe, Komplexität und Verteilung von Nachrichten beschrieben, die in einer BizTalk Server Umgebung verarbeitet werden.
Überlegungen zur Nachrichtengröße
Während BizTalk Server keine Einschränkung für die Nachrichtengröße auferlegt, erfordern praktische Einschränkungen und Abhängigkeiten möglicherweise, dass Sie die Größe Ihrer Nachrichten minimieren, da große Nachrichten mehr Verarbeitungsressourcen erfordern. Wenn die Nachrichtengröße zunimmt, verringert sich der Gesamtdurchsatz (verarbeitete Nachrichten pro Sekunde). Berücksichtigen Sie beim Entwerfen Ihres Szenarios und der Planung der Kapazität die durchschnittliche Nachrichtengröße, den Nachrichtentyp und die Anzahl von Nachrichten BizTalk Server Prozessen. Verwenden Sie keine unnötig langen Attribut- und Tagnamen. Wenn möglich, halten Sie die Länge unter 50 Zeichen. Verwenden Sie beispielsweise keinen 200-stelligen Tagnamen für eine Nachrichtengröße von nur 1 Byte.
Wenn die In-Memory-Größe einer empfangenen Nachricht die Anzahl der Bytes überschreitet, die für die Größe des Großen Nachrichtenfragments angegeben ist (konfigurierbar auf der Seite Gruppeneigenschaften für die BizTalk-Gruppe in der BizTalk Server-Verwaltungskonsole), wird die Nachricht in Fragmente der angegebenen Größe unterteilt. Darüber hinaus werden die Fragmente wie folgt in die Messagebox unter dem Kontext einer MsDTC-Transaktion (Microsoft Distributed Transaction Coordinator) geschrieben:
Wenn die eingehende Nachricht im Kontext einer vorhandenen MSDTC-Transaktion veröffentlicht wird, wird diese Transaktion beim Schreiben der Nachrichtenfragmente in die BizTalk MessageBox-Datenbank verwendet. Wenn die eingehende Nachricht beispielsweise von einem Transaktionsadapter veröffentlicht wird, der so konfiguriert ist, dass Transaktionen erforderlich sind, wird die vorhandene Transaktion beim Schreiben der Nachrichtenfragmente in die MessageBox-Datenbank verwendet.
Wenn die eingehende Nachricht nicht im Kontext einer vorhandenen MSDTC-Transaktion veröffentlicht wird, wird eine neue MSDTC-Transaktion erstellt, um die Nachrichtenfragmente in die MessageBox-Datenbank zu schreiben. In diesem Szenario gelten die folgenden Überlegungen:
Erhöhen Sie den Wert für große Nachrichtenfragmentgröße , um die Häufigkeit zu reduzieren, mit der große Nachrichten fragmentiert werden, und reduzieren Sie die Inzidenz der Erstellung der zugehörigen MSDTC-Transaktionen. Dies empfiehlt sich, da ein übermäßiger Gebrauch von MSDTC-Transaktionen in Bezug auf die Leistung relativ teuer ist. Beachten Sie, dass beim Erhöhen dieses Wertes außerdem auch mehr verfügbarer Arbeitsspeicher verwendet wird.
Wenn es länger als das maximal zulässige MSDTC-Transaktionstimeout von 60 Minuten dauert, um eine Nachricht in das MessageBox-Objekt zu schreiben, wird ein Timeout für die Transaktion ausgeführt, ein Fehler tritt auf, und der Versuch, die Nachricht zu schreiben, schlägt fehl und wird zurückgesetzt. Der Wert für große Nachrichtenfragmente sollte ausreichend erhöht werden, um dieses Problem bei der Verarbeitung sehr großer Nachrichten zu vermeiden. Je nach verfügbarem Arbeitsspeicher empfiehlt sich eine Erhöhung dieses Wertes auf höchstens 1000000 Byte.
Jedes Nachrichtenfragment in einer Nachricht erstellt ein oder mehrere SQL Server-Datenbanksperren für die MessageBox-Datenbank. Wenn die Anzahl der Sperren mehrere Hunderttausend überschreitet, ist es möglich, dass SQL Server Fehler "out of lock" generiert. Wenn dieses Problem auftritt, erhöhen Sie den Wert für große Nachrichtenfragmentgröße, um die Anzahl der Fragmente zu reduzieren (wodurch die Anzahl der SQL Server Datenbanksperren für die MessageBox-Datenbank verringert wird), oder ziehen Sie in Betracht, Ihre MessageBox-Datenbank in einer 64-Bit-Version von SQL Server zu speichern. Die Anzahl der verfügbaren Sperren ist für die 64-Bit-Version von SQL Server deutlich höher als für eine 32-Bit-Version von SQL Server. Die folgende Formel kann verwendet werden, um die maximale Anzahl von Nachrichten pro Austausch zu schätzen, wenn die MessageBox-Datenbank in einer 32-Bit-Version von SQL Server untergebracht ist:
200,000 / (Number of CPUs * BatchSize * MessagingThreadPoolSize)
Weitere Informationen dazu, wie BizTalk Server große Nachrichten verarbeitet, einschließlich Richtlinien für die Verarbeitung großer Nachrichten, finden Sie unter How BizTalk Server Processes Large Messages (https://go.microsoft.com/fwlink/?LinkID=154680).
Überlegungen zum Nachrichtentyp
Nachrichten werden in BizTalk Server in einem von zwei primären Formaten empfangen: XML-Dateien oder Flatfiles. Der Nachrichtentyp sollte aufgrund der unterschiedlichen Ressourcenanforderungen von XML- und Flatfilenachrichten immer im Nachrichtenverteilungsprofil berücksichtigt werden.
XML-Dateien Damit BizTalk Server eine andere Verarbeitung für eine Nachricht als das Passthrough-Routing ausführen kann, muss die Nachricht im XML-Dateiformat vorliegen.
Flatfiles Flatfiles müssen in ein XML-Format analysiert werden, bevor BizTalk Server andere Verarbeitungen als passthrough-Routing ausführen können. Beim Analysieren einer Flatfile und ihrer Konvertierung in eine XML-Datei kann die Dateigröße drastisch ansteigen. Flatfiles enthalten keine XML-Tags, die ihre Daten beschreiben. XML-Dateien schließen ihre Daten dagegen in beschreibende XML-Tags ein. In einigen Szenarien kann die Analyse die Größe einer Flatfile um den Faktor 10 oder mehr erhöhen, je nachdem, wie viele beschreibende Daten in den XML-Tags für die Datei enthalten sind.
Flatfiledokumente, die in einen einzelnen CDATA-Abschnittsknoten in einem XML-Dokument eingeschlossen sind Diese Art von Dokument ist eine Kombination aus XML und Flatfile und ist häufig speicherintensiv, da BizTalk Server das gesamte umschlossene Flatfiledokument vor der Verarbeitung in den Arbeitsspeicher laden muss.
Überlegungen zur Überlastung
Die meisten BizTalk Server Anwendungen empfangen keine Nachrichten mit einer bestimmten konstanten Rate. In der Regel unterliegt die Nachrichtenverarbeitung Spitzen und Tälern. Beispielsweise kann eine Online-Banking-Anwendung eine höhere Menge an Nachrichten zuerst morgens, dann zur Tagesmitte und am Ende des Tages verarbeiten. BizTalk Server Lösungen sollten getestet werden, um sicherzustellen, dass sie diese Überlastungsszenarien verarbeiten können. Um zu bestimmen, wie gut eine BizTalk Server Lösung Überlastungsszenarien verarbeiten kann, sollte der maximale nachhaltige Durchsatz (MST) der BizTalk Server Lösung bestimmt werden. Der MST ist die höchste Last des Nachrichtendatenverkehrs, die ein System unbegrenzt in einer Produktionsumgebung verarbeiten kann. Weitere Informationen zu MST finden Sie unter Planning for Sustainable Performance (https://go.microsoft.com/fwlink/?LinkID=158065) and What Is Sustainable Performance? (https://go.microsoft.com/fwlink/?LinkID=132304) in der BizTalk Server Dokumentation.
Schemakomplexität
Der Durchsatz für die Nachrichtenanalyse (insbesondere die Flatfileanalyse) wird von der Komplexität der Schemas beeinflusst. Mit zunehmender Schemakomplexität nimmt die Gesamtleistung ab. Reduzieren Sie beim Entwerfen von Schemas die Länge von Knotennamen, und verschieben Sie höhergestufte Eigenschaften an den Anfang des Schemas. Dies reduziert die Abrufzeit und erhöht dadurch die Leistung.
Zuordnungskomplexität
Je nach Komplexität der Karten kann die Kartentransformation ressourcenintensiv sein. Mit zunehmender Kartenkomplexität nimmt die Gesamtleistung ab. Um die Gesamtleistung zu verbessern, minimieren Sie die Anzahl von Links und Funktoiden, die in Ihren Karten verwendet werden, insbesondere Funktoide, die externe Ressourcen wie das Funktoid DB-Suche aufrufen.
Überlegungen zur Flatfileanalyse
Die beiden Faktoren, die die größte Auswirkung auf die Leistung der Flatfileanalyse haben, sind Dateigröße und Schemakomplexität. Ein mehrdeutiges Schema ist ein Schema, das viele optionale Felder enthält. Wenn große Dateigrößen verwendet werden, kann ein Schema mit vielen optionalen Feldern die Leistung beeinträchtigen, da größere Dateien möglicherweise mit verschiedenen Verzweigungen des Schemas übereinstimmen. Die Schemakomplexität hat weniger Auswirkungen auf kleinere Dateien als auf größere Dateien.