Optimieren der Leistung des Geschäftsregelmoduls (Business Rule Engine, BRE)

Die folgenden Faktoren sollten bei der Implementierung der Business Rule Engine (BRE) in einer BizTalk Server Lösung berücksichtigt werden:

Faktentypen

Die Regel-Engine benötigt weniger Zeit für den Zugriff auf .NET-Fakten im Vergleich zu der Zeit, die für den Zugriff auf XML- und Datenbankfakten benötigt wird. Wenn Sie die Wahl haben, in einer Richtlinie entweder .NET- oder XML- oder Datenbankfakten zu verwenden, sollten Sie die Verwendung von .NET-Fakten in Betracht ziehen, um die Leistung zu verbessern.

Datentabelle und Datenverbindung

Wenn die Größe des Datasets klein ist (< etwa 10), bietet die TypedDataTable-Bindung eine bessere Leistung als die DataConnection-Bindung . Die DataConnection-Bindung ist jedoch besser als die TypedDataTable-Bindung , wenn das Dataset groß ist (größer oder gleich 10 Zeilen ungefähr). Daher sollten Sie basierend auf der geschätzten Größe des Datasets entscheiden, ob Die DataConnection-Bindung oder die TypedDataTable-Bindung verwendet werden soll.

Fakten-Retriever

Ein Fact Retriever implementiert Standardmethoden, die in der Regel verwendet werden, um der Regel-Engine langfristige und sich langsam ändernde Fakten zu liefern, bevor eine Richtlinie ausgeführt wird. Die Engine speichert diese Fakten zwischen und nutzt sie in mehreren Ausführungszyklen. Anstatt jedes Mal, wenn Sie die Regel-Engine aufrufen, eine statische oder ziemlich statische Tatsache zu übermitteln, sollten Sie einen Fakten-Retriever erstellen, der die Tatsache zum ersten Mal übermittelt, und dann die Tatsache nur bei Bedarf im Arbeitsspeicher aktualisiert.

Regelpriorität

Die Prioritätseinstellung für eine Regel kann auf beiden Seiten von 0 liegen, wobei größere Zahlen eine höhere Priorität haben. Aktionen werden in der Reihenfolge von der höchsten Priorität bis zur niedrigsten Priorität ausgeführt. Wenn die Richtlinie das Vorwärtsverkettungsverhalten mithilfe von Assert/Update-Aufrufen implementiert, kann die Verkettung mithilfe der Prioritätseinstellung optimiert werden. Angenommen, Rule2 hat eine Abhängigkeit von einem wert, der von Rule1 festgelegt ist. Wenn Regel1 eine höhere Priorität erhält, wird Regel2 nur ausgeführt, nachdem Rule1 den Wert ausgelöst und aktualisiert hat. Wenn Regel2 dagegen eine höhere Priorität erhält, könnte sie einmal ausgelöst und dann nach dem Auslösen von Regel1 erneut ausgelöst werden und die Tatsache aktualisieren, dass Rule2 eine Bedingung verwendet. Dies kann zwar ein richtiges Ergebnis liefern, aber wenn Regel1 in diesem Szenario eine höhere Priorität erhält, wird eine bessere Leistung erzielt.

Aufrufe aktualisieren

Die Update-Funktion bewirkt, dass alle Regeln, die die aktualisierten Fakten verwenden, neu ausgewertet werden. Aktualisierungsfunktionsaufrufe können teuer sein, insbesondere wenn ein großer Satz von Regeln beim Aktualisieren von Fakten neu bewertet wird. Es gibt Situationen, in denen dieses Verhalten vermieden werden kann. Betrachten Sie beispielsweise die folgenden Regeln.

Regel1:

IF PurchaseOrder.Amount > 5   
THEN StatusObj.Flag = true; Update(StatusObj)  

Regel2:

IF PurchaseOrder.Amount <= 5   
THEN StatusObj.Flag = false; Update(StatusObj)  

Alle verbleibenden Regeln der Richtlinie verwenden StatusObj.Flag in ihren Bedingungen. Wenn Update für das StatusObj-Objekt aufgerufen wird, werden daher alle Regeln neu ausgewertet. Unabhängig vom Wert des Felds Betrag werden alle Regeln außer Regel1 oder Regel2 zweimal ausgewertet, einmal vor dem Update-Aufruf und einmal nach dem Update-Aufruf .

Um den damit verbundenen Mehraufwand zu verringern, können Sie den Wert des Flagfelds vor dem Aufrufen der Richtlinie auf false festlegen und dann nur Rule1 in der Richtlinie verwenden, um das Flag festzulegen. In diesem Fall wird Update nur aufgerufen, wenn der Wert des Felds Betrag größer als 5 ist, und die Update-Funktion wird nicht aufgerufen, wenn der Wert von Amount kleiner oder gleich 5 ist. Daher werden alle Regeln außer Regel1 oder Regel2 nur zweimal ausgewertet, wenn der Wert des Felds Betrag größer als 5 ist.

Verwendung logischer OR-Operatoren

Die Verwendung einer zunehmenden Zahl logischer OR-Operatoren in Bedingungen erzeugt zusätzliche Permutationen, die das Analysenetzwerk der Regel-Engine erweitern. Im Hinblick auf die Leistungsoptimierung ist es besser, die Bedingungen in atomarische Regeln aufzuteilen, die keine logischen OR-Operatoren enthalten.

Zwischenspeicherungseinstellungen

Die Regel-Engine verwendet zwei Caches. Die erste wird vom Updatedienst und die zweite von jedem BizTalk-Prozess verwendet. Wenn eine Richtlinie zum ersten Mal verwendet wird, fordert der BizTalk-Prozess die Richtlinieninformationen vom Updatedienst an. Der Updatedienst ruft die Richtlinieninformationen aus der Datenbank der Regel-Engine ab, speichert sie zwischen und gibt die Informationen an den BizTalk-Prozess zurück. Der BizTalk-Prozess erstellt ein Richtlinienobjekt basierend auf diesen Informationen und speichert das Richtlinienobjekt in einem Cache, wenn die zugehörige Regel-Engine instance die Ausführung der Richtlinie abgeschlossen hat. Wenn dieselbe Richtlinie erneut aufgerufen wird, verwendet der BizTalk-Prozess das Richtlinienobjekt aus dem Cache wieder, sofern es verfügbar ist. Wenn der BizTalk-Prozess Informationen zu einer Richtlinie vom Updatedienst anfordert, sucht der Updatedienst nach den Richtlinieninformationen im Cache, sofern sie verfügbar sind. Alle 60 Sekunden überprüft der Updatedienst außerdem, ob die Richtlinie in der Datenbank aktualisiert wurde. Wenn Updates vorhanden sind, ruft der Updatedienst die Informationen ab und speichert die aktualisierten Informationen zwischen.

Es gibt drei Optimierungsparameter für die Regel-Engine, die sich auf diese Caches beziehen: CacheEntries, CacheTimeout und PollingInterval. Sie können die Werte für diese Parameter entweder in der Registrierung oder in einer Konfigurationsdatei angeben. Der Wert des CacheEntries-Parameters ist die maximale Anzahl von Einträgen im Cache und ist standardmäßig auf den Wert 32 festgelegt. Sie können den Wert des CacheEntries-Parameters erhöhen, um die Leistung in bestimmten Szenarien zu verbessern. Angenommen, Sie verwenden wiederholt 40 Richtlinien. Sie könnten den Wert des CacheEntries-Parameters auf 40 erhöhen, um die Leistung zu verbessern. Dadurch kann der Updatedienst Cachedetails von bis zu 40 Richtlinien im Arbeitsspeicher verwalten.

Der Wert von CacheTimeout ist die Zeit in Sekunden, zu der ein Eintrag im Cache des Updatediensts beibehalten wird. Mit anderen Worten, der CacheTimeout-Wert bezieht sich darauf, wie lange ein Cacheeintrag für eine Richtlinie im Cache verwaltet wird, ohne darauf verwiesen zu werden. Der Standardwert des CacheTimeout-Parameters beträgt 3600 Sekunden oder eine Stunde. Dies bedeutet, dass der Eintrag gelöscht wird, wenn nicht innerhalb einer Stunde auf den Cacheeintrag verwiesen wird. In einigen Fällen kann es vorteilhaft sein, den Wert des CacheTimeout-Parameters zu erhöhen, um die Leistung zu verbessern. Wenn beispielsweise alle zwei Stunden eine Richtlinie aufgerufen wird, wird die Leistung der Richtlinienausführung verbessert, indem der CacheTimeout-Parameter auf einen Wert höher als zwei Stunden erhöht wird.

Der PollingInterval-Parameter der Regel-Engine definiert die Zeit in Sekunden, zu der der Updatedienst die Datenbank der Regel-Engine auf Updates überprüft. Der Standardwert für den Parameter PollingInterval beträgt 60 Sekunden. Wenn Sie wissen, dass die Richtlinien überhaupt nicht oder nur selten aktualisiert werden, können Sie diesen Parameter in einen höheren Wert ändern, um die Leistung zu verbessern.

SideEffects-Eigenschaft

Die Klassen ClassMemberBinding, DatabaseColumnBinding und XmlDocumentFieldBinding verfügen über eine Eigenschaft mit dem Namen SideEffects. Diese Eigenschaft bestimmt, ob der Wert des gebundenen Felds, des Members oder der Spalte zwischengespeichert wird. Der Standardwert der SideEffects-Eigenschaft in den Klassen DatabaseColumnBinding und XmlDocumentFieldBinding ist false. Der Standardwert der SideEffects-Eigenschaft in der ClassMemberBinding-Klasse ist true. Wird innerhalb einer Richtlinie zum zweiten Mal oder später auf ein Feld eines XML-Dokuments oder auf eine Spalte einer Datenbanktabelle zugegriffen, wird sein Wert daher aus dem Cache abgerufen. Wird jedoch zum zweiten Mal oder später auf ein Member eines .NET-Objekts zugegriffen, wird der Wert aus dem .NET-Objekt und nicht aus dem Cache abgerufen. Das Festlegen der SideEffects-Eigenschaft einer .NET ClassMemberBinding auf false verbessert die Leistung, da der Wert des Felds ab dem zweiten Mal aus dem Cache abgerufen wird. Dies kann nur programmgesteuert geschehen. Das Business Rule Composer-Tool macht die SideEffects-Eigenschaft nicht verfügbar.

Instanzen und Selektivität

Die Klassen XmlDocumentBinding, ClassBinding und DatabaseBinding verfügen über zwei Eigenschaften: Instanzen und Selektivität. Der Wert für Instances ist die erwartete Anzahl der Instanzen der Klasse im Arbeitsspeicher. Der Wert von Selektivität ist der Prozentsatz der Klasseninstanzen, die die Regelbedingungen erfolgreich übergeben. Die Regel-Engine optimiert die Auswertung von Bedingungen anhand dieser Werte, sodass bei der Auswertung von Bedingungen zunächst eine möglichst geringe Anzahl von Instanzen und danach die übrigen Instanzen verwendet werden. Wenn Sie über kenntnisse über die Anzahl der Instanzen des Objekts verfügen, würde das Festlegen der Instances-Eigenschaft auf diesen Wert die Leistung verbessern. Wenn Sie bereits wissen, in welcher Prozentzahl diese Objekte die Bedingungen übergeben, würde das Festlegen der Selectivity-Eigenschaft auf diesen Wert die Leistung verbessern. Werte für diese Parameter können nur programmgesteuert festgelegt werden. Im Geschäftsregelersteller werden sie nicht angezeigt.

Weitere Informationen

Optimieren der Leistung von BizTalk Server