Entwerfen eines leistungsfähigen Adapters

Zur Leistungsverbesserung sollten alle Adapter Batches unterstützen. Dies bezieht sich in erster Linie auf das Übermitteln von Nachrichtenbatches, Übertragen von Batches und Durchführen von Vorgängen mit Nachrichten in Batches. Adapter sollten konfigurierbare leistungsbezogene Attribute zugänglich machen, beispielsweise die Größe von Batches oder die Anzahl von Bytes in einem Batch, die über die Benutzeroberfläche des jeweiligen Adapters zur Entwurfszeit konfigurierbar sind.

Wie bereits erwähnt, sollten Sendeadapter stets nicht blockierende Sendevorgänge durchführen, um eine Leistungsbeeinträchtigung des Sendehosts zu vermeiden. Ein weiteres Blockieren der von der Messaging-Engine bereitgestellten APIs wird nicht empfohlen.

Das Schreiben und Lesen des Nachrichtenkontexts wirkt sich auf die Leistung zur Laufzeit aus. Grundsätzlich sollten Adapter Lese- und Schreibvorgänge sowie das Heraufstufen einer übermäßigen Anzahl von Nachrichtenkontexteigenschaften vermeiden. Das Heraufstufen von Eigenschaften verursacht einen zusätzlichen Leistungsabfall, weil zur Laufzeit für jede heraufgestufte Eigenschaft eine Prüfung des Abonnements erfolgt. Allerdings müsste ein Adapter eine hohe Anzahl an Eigenschaften heraufstufen, damit dies bemerkbare Auswirkungen auf die Leistung hat. Es hat sich jedoch bewährt, nur die Eigenschaften heraufzustufen, die tatsächlich heraufgestuft werden müssen.

Einschränken des Sendens und Empfangens

Wenn die Auslastung der BizTalk-Engine über dem konfigurierten Schwellenwert liegt, schränkt die Engine Adapter und Orchestrierungen ein, um eine optimale Leistung sicherzustellen. Auf der Empfangsseite wird der Aufruf des Adapters an IBTTransportBatch.Done blockiert, wenn die Workload auf der Engine einen bestimmten Schwellenwert überschreitet, bis die Last ausreichend zurückgegangen ist. Das zwingt den Adapter, neue Aufträge erst an die Engine zu übermitteln, wenn die Engine verfügbar ist. Wenn die Engine auf der Sendeseite das Senden von ausgehenden Nachrichten des Adapters einschränkt, übermittelt die Engine keine neuen zu übertragenden Nachrichten, bis dessen Auslastung verringert wurde.

Aus diesen Gründen muss ein Adapter nicht eingeschränkt werden, es sei denn, es ist wirklich erforderlich, z B. um die Anzahl an Verbindungen mit einem Back-End-System zu begrenzen. Solche Szenarien werden weder von der Engine noch vom Adapterframework unterstützt.

Sie können die Anzahl an Nachrichten, die von einem benutzerdefinierten Sendeadapter gesendet wurden, auf mehrere Arten einschränken. Dies ist abhängig davon, ob Sie Zugriff auf den Quellcode des Adapters haben.

Leistungsverbesserung durch Einschränkungen auf Sendeseite

Wenn Sie Zugriff auf den Quellcode des Adapters haben, können Sie mit heuristischen Methoden die maximale Anzahl von Nachrichten ermitteln, die sich in der Warteschlange befinden und zu einem beliebigen Zeitpunkt gesendet werden sollen. Wenn die Messaging-Engine die TransmitMessage -Methode aufruft und dem Sendeadapter eine neue Nachricht übergibt, können Sie entweder den Thread blockieren oder überprüfen, ob die Anzahl der Nachrichten in der Warteschlange größer als der zuvor ermittelte Maximalwert ist. Wenn die maximale Anzahl von Nachrichten überschritten wurde, können Sie die Resubmit -Methode verwenden, um die Nachricht erneut an die Messaging-Engine zu übermitteln. Beachten Sie bei synchronen Adaptern, dass diese Nachricht bereits blockiert wäre.

Wenn Sie den Quellcode für den Adapter nicht steuern, können Sie die Anzahl der Nachrichten in der Warteschlange ändern, indem Sie den Highwatermark-Wert in der tabelle Adm_serviceclass in der BizTalk Management-Datenbank ändern. Der maximale Wert für die Highwatermark-Eigenschaft ist 200. Sie können auch den Wert für die Lowwatermark-Eigenschaft in einen kleineren Wert ändern.

Beachten Sie, dass der Wert der Highwatermark-Eigenschaft für asynchrone Adapter die Anzahl der Nachrichten bestimmt, die die Messaging-Engine dem Adapter übermittelt hat. Die Messaging-Engine übergibt sie an den Adapter über die TransmitMessage -Methode Diese Nachrichten können in ihrer Übertragung noch ausstehend sein, z. B. wenn der Adapter keinen entsprechenden Aufruf der DeleteMessageMethoden , Resubmit, MoveToNextTransport, oder Microsoft.BizTalk.TransportProxy.Interop.BatchOperationType.MoveToSuspendQ durchgeführt hat. Bei synchronen Adaptern erfasst die Highwatermark-Eigenschaft nur die Anzahl der Nachrichten, die die Messaging-Engine mithilfe der TransmitMessage-Methode an den Adapter übergeben hat, da dieser Aufruf synchron verarbeitet wird und den aufrufenden Messaging Engine-Thread blockiert.

Wenn Sie einen Sendeadapter für ein Protokoll programmieren, das schon an sich langsam ist (bspw. HTTP, FTP oder bidirektionales SOAP), beachten Sie Folgendes:

• Ein solcher Adapter empfängt Nachrichten zur Übertragung von der BizTalk-Messaging-Engine möglicherweise schneller, als dieser sie übertragen kann. Diese Abweichung führt in verschiedenen Bereichen zu Problemen. Die zu übertragenden Nachrichten verbleiben im Arbeitsspeicher und lasten den virtuellen Speicher aus, dies führt zur Verlangsamung des gesamten Systems.

• Der Adapter lastet möglicherweise protokollspezifische Ressourcen aus. Er könnte beispielsweise zu viele gleichzeitige Verbindungen mit einem Server öffnen, die den Remoteserver unterbrechen könnten.

• Der Adapter bzw. dessen Verwendung beeinflussen möglicherweise andere Adapter. Wenn z B. für einen bestimmten Adapter zu viele Nachrichten in der Warteschlange vorhanden sind, stoppt die Messaging-Engine die Ausgabe von Anforderungen an andere Sendeadapter in diesem Prozess.

  Eine Lösung ist, die langsamen und schnellen Adapter jeweils anderen BizTalk-Hosts zuzuweisen und die Anzahl an Nachrichten durch Verwenden der Einstellungen "High Watermark" und "Low Watermark" zu steuern.

Leistungsverbesserung durch Einschränkungen auf Empfangsseite

Es gibt viele Situationen, in denen ein Empfangsadapter Nachrichten schneller empfängt, als der Rest des Systems zur Verarbeitung von Nachrichten benötigt. In einer solchen Situation bildet die MessageBox-Datenbank einen Rückstand. Dadurch sinkt die Leistung des gesamten Systems erheblich.

Sollte dies mit Ihrem Adapter geschehen, befolgen Sie eine der folgenden Vorgehensweisen, um die Geschwindigkeit des Empfangsadapters zu verringern:

• Verringern Sie die Threadpoolgröße der Messaging-Engine. Steuern Sie die Anzahl an Threads, die die Messaging-Engine zum Veröffentlichen von Nachrichten an die MessageBox verwendet. Durch Verringern der Anzahl an Threads senken Sie die Rate, mit der der Empfangsadapter Nachrichten in der MessageBox empfängt. Diese Einstellung müssen Sie nur für den Host vornehmen, der dem Empfangshandler des Adapters zugeordnet ist. Nehmen Sie diese Einstellung nicht für den Host vor, der dem Sendehandler des Adapters zugeordnet ist, es sei denn, Sie möchten den Sendeapter ebenfalls verlangsamen.

• Verringern Sie die Batchgröße des Adapters. Die meisten schnellen Empfangsadapter veröffentlichen Nachrichten an die MessageBox in Batches. Die Größe dieser Batches ist üblicherweise auf der Eigenschaftenseite für den Empfangsspeicherort konfigurierbar. Durch Verringern der Batchgröße können Sie den Gesamtdurchsatz an Nachrichten senken, die im System verarbeitet werden.

• Ändern Sie andere adapterspezifische Einstellungen. Nach dem Durchführen der beiden vorherigen Schritte haben Sie die Möglichkeit, andere Adapterparameter einzustellen, um den Durchsatz noch weiter zu verringern. Einige Adapter legen interne Parameter offen, die Sie zum Verringern des Durchsatzes verwenden können. Der MQSeries-Adapter besitzt z. B. eine Einstellung für Geordnete Übermittlung. Geordnete Übermittlung gibt an, dass der Adapter einen Nachrichtenbatch veröffentlicht, auf den Abschluss der Veröffentlichung wartet und anschließend den nächsten Batch veröffentlicht. Durch Aktivieren dieser Einstellung entfernen Sie im Wesentlichen das Parallelverhalten des Empfangsadapters. Wenn Sie die Parameter entgegengesetzt einstellen, können Sie die Empfangsrate eines Empfangsadapters erhöhen.

  Ein Adapter kann die erforderliche Anzahl an Batches an den Transportproxy übermitteln. Wenn das System stark beansprucht wird, blockiert ein Aufruf der Done-Methode der IBTTransportBatch-Schnittstelle die Nachricht, bis die erforderlichen Ressourcen für das System freigegeben sind.

Planen des asynchronen Empfangens und Sendens

Die Messaging-APIs des BizTalk Servers bieten eine umfangreiche Unterstützung für eine asynchrone Programmierung. Wenn Sie einen skalierbaren Adapter programmieren möchten, sollten Sie die Verwendung des asynchronen Modells bevorzugen, da dieses Modell eine bessere Parallelität aufweist.

Wenn ein Adapter auf der Empfangsseite einen Batch von Nachrichten an die BizTalk-Messaging-Engine übermittelt (durch Aufrufen von IBTTransportBatch::D one), führt die Messaging-Engine die Arbeit mithilfe des internen Threadpools in die Warteschlange und gibt sofort zurück. Die Engine verarbeitet die Nachrichten in einem eigenen Thread, wodurch der Adapter weitere Nachrichten aus der Quelle lesen und diese übermitteln kann, ohne auf das Verarbeiten von vorherigen Nachrichten warten zu müssen.

Auf der Sendeseite kann Ihr Adapter asynchron oder synchron ausgerichtet sein. Wenn das Protokoll asynchrone Vorgänge unterstützt, sollen Sie diese jedoch beim Programmieren eines skalierbaren Adapters verwenden. Datei- und HTTP-Sendeadapter sind z. B. vollständig asynchron ausgelegt und führen sehr wenige Blockierungs-/Synchronvorgänge aus.

Asynchrone Vorgänge stellen sicher, dass sowohl die Messaging-Engine und Ihr Adapter die jeweiligen Aufgaben weiter parallel durchführen und untereinander nicht auf die normale Nachrichtenverarbeitung warten.

Leistungsverbesserung durch Batchverarbeitung

Batchverarbeitung ist ein guter Ausgangspunkt zum Programmieren eines skalierbaren Adapters. Das gilt für Sende- und Empfangsadapter. Jeder Batch durchläuft eine Datenbanktransaktion im BizTalk Server, auch wenn der Adapter nicht transaktional ausgelegt ist. Da mit jeder Transaktion eine festgelegte Verzögerung verbunden ist, sollten Sie versuchen, die Anzahl an Transaktionen zu minimieren, indem Sie mehrere Vorgänge in einen einzelnen Batch gruppieren.

Blockieren des .NET-Threadpools vermeiden

Das Programmieren von BizTalk-Adaptern ist eine Übung im Programmieren von .NET-Laufzeitcode; das Programmieren von .NET-Laufzeitcode ist ausnahmslos eine Übung im asynchronen Programmieren.

Das Blockieren des .NET-Threadpools ist eine allgemeine Gefahr beim asynchronen Programmieren in .NET. Besonders für einen Programmierer von BizTalk-Adaptern gilt es, dies zu vermeiden.

Der .NET-Threadpool ist zwar eine begrenzte, aber im großen Rahmen freigegebene Ressource. Es ist einfach, Code zum Verwenden eines Threads des .NET-Threadpools zu schreiben, diesen lange Zeit zu belegen und so das Ausführen anderer Arbeitselemente zu blockieren.

Wenn Sie BeginInvoke oder einen Timer verwenden, verwenden Sie einen .NET-Threadpoolthread. Wenn Sie mehrere Aufgaben erledigen müssen (z. B. das Kopieren von Nachrichten aus MQSeries in BizTalk Server), sollten Sie ein Arbeitselement (einen Nachrichtenbatch in BizTalk Server) ausführen und dann erneut im Threadpool warteschlangen, wenn mehr Arbeit zu erledigen ist. Sitzen Sie niemals in einer while Schleife im Thread.

Konkret bedeutet dies, Schleifen durch wiederholte Aufrufe von BeginInvoke zu ersetzenwhile. Durch diese einfache Änderung verbessern Sie erheblich Reaktionszeit und dezentrale Skalierbarkeit der gesamten Implementierung.

Wählen der korrekten Maßeinheit beim Begrenzen der Batchgröße

Wenn Sie Nachrichten in Batches an BizTalk Server übermitteln, begrenzen Sie die Batchgröße nicht nur aufgrund der Nachrichtenanzahl. Berücksichtigen Sie, was geschieht, wenn ein Adapter für einen Batch konfiguriert wurde, der nur auf der Nachrichtenanzahl basiert: Wenn die Batchgröße zwei beträgt und der Adapter vier Nachrichten der Größe 4 KB, 8 KB, 1 MB bzw. 5 MB erhält, hat der erste Batch eine Größe von 12 KB und der zweite Batch eine Größe von 6 MB.

Da die BizTalk-Messaging-Engine alle Nachrichten in einem Batch sequenziell verarbeitet, wird der zweite Batch in diesem Beispiel viel langsamer als der erste Batch verarbeitet. Dies mindert den Durchsatz erheblich. Um dieses Problem zu umgehen, führen Sie die Batchverarbeitung aufgrund der Nachrichtenanzahl und der Gesamtanzahl der Bytes (d. h. Batchgröße in Bytes) in einem Batch durch. Es gibt keine allgemein gültige Gesamtanzahl der Bytes. Überschreitet die Batchgröße in einem üblichen Verarbeitungszenario allerdings 1 MB, werden Sie eine schlechte Parallelität und schlechten Durchsatz feststellen.

Im Allgemeinen sind Adapter nachrichtenagnostisch und kennen die Größe der Nachrichten in der Produktionsumgebung nicht. Die Größe der eingehenden Nachrichten schwankt erheblich. Verwenden Sie daher immer die Nachrichtenanzahl und die Gesamtanzahl der Bytes zum Erstellen des Batchs.