Freigeben über

Überlegungen zur Leistung bei Verwendung der Regel-Engine

  • Artikel

In diesem Thema wird erläutert, welche Leistung die Regel-Engine in verschiedenen Szenarien und mit verschiedenen Werten für die Konfigurations-/Optimierungsparameter bietet.

Faktentypen

Der Zugriff der Regel-Engine auf .NET-Fakten erfolgt schneller als auf XML- und Datenbankfakten. Wenn Sie in einer Richtlinie die Möglichkeit haben, .NET-, XML- oder Datenbankfakten zu verwenden, sollten Sie zur Erzielung einer besseren Leistung .NET-Fakten verwenden.

Datentabellenbindung im Vergleich zu Datenverbindungsbindung

Wenn die Größe des Datasets klein ist (weniger als etwa 10 Zeilen), ist die TypedDataTable-Bindung besser als die DataConnection-Bindung . Wenn das Dataset groß ist (größer oder gleich etwa 10 Zeilen), ist die DataConnection-Bindung besser als die TypedDataTable-Bindung . Daher sollten Sie basierend auf der geschätzten Größe des Datasets entscheiden, ob Sie die DataConnection-Bindung oder die TypedDataTable-Bindung verwenden möchten.

Fact Retriever

Sie können einen Faktenabrufer erstellen. Ein Faktenabrufer ist ein Objekt, das Standardmethoden implementiert und damit üblicherweise langfristige, sich langsam ändernde Fakten vor Ausführung der Richtlinie an die Regel-Engine übergibt. Die Engine speichert diese Fakten zwischen und nutzt sie in mehreren Ausführungszyklen. Anstatt bei jedem Aufruf der Regel-Engine einen statischen oder vergleichsweise statischen Fakt zu senden, sollten Sie einen Faktenabrufer erstellen, der den Fakt beim ersten Mal sendet und ihn danach 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 der Reihe nach ausgeführt, von der höchsten Priorität bis zur niedrigsten Priorität. Wenn die Richtlinie das Vorwärtsverkettungsverhalten mithilfe von Assert/Update-Aufrufen implementiert, kann die Verkettung mithilfe der Prioritätseinstellung optimiert werden. Angenommen, Regel2 hat eine Abhängigkeit von einem Wert, der von Rule1 festgelegt wird. 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, kann sie einmal ausgelöst und dann erneut ausgelöst werden, nachdem Rule1 ausgelöst und die Tatsache aktualisiert, dass Rule2 in einer Bedingung verwendet wird. Dadurch werden nicht unbedingt die richtigen Ergebnisse erzielt. Das zweifache Auslösen hat jedoch deutlichere Auswirkungen auf die Leistung als das einfache Auslösen.

Update-Aufrufe

Die Update-Funktion aktualisiert eine Tatsache, die im Arbeitsspeicher der Regel-Engine vorhanden ist, und bewirkt, dass alle Regeln, die die aktualisierte Tatsache in Bedingungen verwenden, neu ausgewertet werden. Aktualisierungsfunktionsaufrufe können teuer sein, insbesondere wenn viele Regeln aufgrund der Aktualisierung der Fakten neu bewertet werden müssen. Es gibt Situationen, in denen Sie die erneute Auswertung der Regeln vermeiden können. Betrachten Sie z. B. folgende 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 und Regel2 zweimal ausgewertet, einmal vor dem Update-Aufruf und einmal nach dem Update-Aufruf .

Stattdessen können Sie den Wert des Flagfelds auf false festlegen, bevor Sie die Richtlinie aufrufen, 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 Update wird nicht aufgerufen, wenn der Betrag kleiner oder gleich 5 ist. Daher werden alle Regeln außer Regel1 und Regel2 nur zweimal ausgewertet, wenn der Wert des Felds Betrag größer als 5 ist.

Verwenden von logischen OR-Operatoren

Die Regel-Engine ist für die Ausführung logischer AND-Operatoren optimiert und rekonstruiert die von ihr analysierte Regel in einer disjunktiven Normalform, sodass der OR-Operator nur auf der obersten Ebene verwendet wird. Die Verwendung einer steigenden Anzahl logischer OR-Operatoren unter Bedingungen führt zu zusätzlichen Permutationen, die das Analysenetzwerk der Regel-Engine erweitern, und es kann lange dauern, bis die Regel-Engine die Regel normalisiert. Die folgende Liste enthält mögliche Problemumgehungen:

  • Ändern Sie die Regel so, dass sie sich in einer disjunktiven Normalform befindet, sodass sich der OR-Operator nur auf der obersten Ebene befindet. Beachten Sie, dass das Entwickeln einer Regel in der disjunktiven Normalform im Geschäftsregelersteller komplex sein kann. Unter Umständen möchten Sie die Regel daher programmgesteuert erstellen.

  • Entwickeln Sie eine Hilfskomponente, die die OR-Vorgänge ausführt und einen booleschen Wert zurückgibt, und verwenden Sie die Komponente in der Regel.

  • Teilen Sie die Regel ggf. in mehrere Regeln auf, und lassen Sie die Regeln auf ein Kennzeichen prüfen, das durch eine zuvor ausgeführte Regel festgelegt wurde. Sie können auch ein Objekt verwenden, das durch eine zuvor ausgeführte Regel übergeben wird. Das folgende Beispiel zeigt diesen Vorgang:

    • Regel 1: IF (a == 1 ODER a == 3) THEN b = true

      Regel 2: if (b == true) THEN ...

    • Regel 1: IF (a == 1 ODER a == 3) THEN assert(new c())

      Regel 2: WENN (c.flag == true) THEN ...

Cacheeinstellungen

Die Regel-Engine verwendet zwei Caches. Der erste ist im Aktualisierungsdienst enthalten, der zweite in jedem BizTalk-Prozess. Bei der ersten Verwendung einer Richtlinie fordert der BizTalk-Prozess die Richtlinieninformationen vom Aktualisierungsdienst an. Der Aktualisierungsdienst ruft die Richtlinieninformationen aus der Regel-Engine-Datenbank ab, legt sie im Cache ab und gibt die Informationen an den BizTalk-Prozess zurück. Der BizTalk-Prozess erzeugt anhand dieser Informationen ein Richtlinienobjekt und legt dieses in einem Cache ab, wenn die verknüpfte Instanz der Regel-Engine die Ausführung der Richtlinie abgeschlossen hat. Wird die gleiche Richtlinie erneut aufgerufen, wird das Richtlinienobjekt vom BizTalk-Prozess wiederverwendet, falls es noch im Cache verfügbar ist.

Analog dazu sucht der Aktualisierungsdienst zunächst in seinem Cache nach den Richtlinieninformationen, wenn der BizTalk-Prozess diese Informationen vom Aktualisierungsdienst anfordert. Der Aktualisierungsdienst überprüft zudem alle 60 Sekunden (minütlich), ob an der Richtlinie in der Datenbank Aktualisierungen vorgenommen wurden. Ist dies der Fall, ruft der Aktualisierungsdienst die Informationen ab und legt die aktualisierten Informationen im Cache ab.

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 von CacheEntries ist die maximale Anzahl von Einträgen im Cache. Der Standardwert von CacheEntries ist 32. Möglicherweise möchten Sie den Wert des CacheEntries-Parameters erhöhen, um die Leistung in einigen Fällen zu verbessern. Angenommen, 40 Richtlinien werden wiederholt verwendet. In diesem Fall können Sie den Wert von CacheEntries auf 40 erhöhen, um die Leistung zu verbessern. Dadurch kann der Aktualisierungsdienst Details zu maximal 40 Richtlinien zwischenspeichern. Außerdem ist der BizTalk-Dienst dann in der Lage, bis zu 40 Richtlinieninstanzen zwischenzuspeichern. Im Cache des BizTalk-Diensts können somit auch mehrere Instanzen einer Richtlinie abgelegt werden.

Der Wert von CacheTimeout ist die Zeit (in Sekunden), in der Einträge aus dem Updatedienstcache altern. Mit anderen Worten, der CacheTimeout-Wert bezieht sich darauf, wie lange ein Cacheeintrag für eine Richtlinie im Cache aufbewahrt wird, wenn keine Verweise darauf vorhanden sind. Der Standardwert von CacheTimeout beträgt 3600 Sekunden (eine Stunde). Wenn innerhalb einer Stunde kein Verweis auf den Cacheeintrag erfolgt, wird er gelöscht. In einigen Fällen können Sie den CacheTimeout-Wert erhöhen, um die Leistung zu verbessern. Angenommen, die Richtlinie wird alle zwei Stunden aufgerufen. Sie können die Leistung der Richtlinienausführung verbessern, indem Sie den Wert des CacheTimeout-Parameters auf einen Wert von mehr als zwei Stunden erhöhen.

Der PollingInterval-Parameter für die Regel-Engine definiert die Zeit in Sekunden für das Intervall, in dem der Updatedienst die Datenbank der Regel-Engine auf Updates überprüft. Der Standardwert für den Parameter PollingInterval beträgt 60 Sekunden (eine Minute). Wenn Sie wissen, dass die Richtlinien gar nicht oder nur sehr selten aktualisiert werden, können Sie diesen Wert erhöhen, um die Leistung zu optimieren.

Eigenschaft "SideEffects"

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.

Instances und Selectivity

Die Klassen XmlDocumentBinding, ClassBinding und DatabaseBinding verfügen über zwei Eigenschaften: Instanzen und Selektivität. Der Wert von Instances ist die erwartete Anzahl von 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.