Hohe CPU beim Ausführen einer BRE-Richtlinie

Dieser Artikel enthält Informationen dazu, dass bei Verwendung einer BRE-Richtlinie (Business Rules Engine) innerhalb einer Orchestrierung oder mithilfe des Business Rules Frameworks zum Ausführen einer BRE-Richtlinie eine hohe CPU-Auslastung für den Prozess, der die Richtlinie ausführt, auftreten kann.

Ursprüngliche Produktversion:   BizTalk Server
Ursprüngliche KB-Nummer:   2498797

Beispiel für das Szenario mit hoher CPU-Auslastung

Es gibt ein Beispiel dafür, dass ein ASMX-Webdienst die Microsoft.RuleEngine.Policy Klasse verwenden kann, um eine BRE-Richtlinie auszuführen. In diesem Szenario ist die Leistung langsam, und der w3wp.exe Prozess verwendet eine hohe CPU. Wenn die Richtlinie innerhalb einer Orchestrierung ausgeführt wird, verwendet der btsntsvc.exe- oder btsntsvc64.exe-Prozess eine hohe CPU.

BRE verfügt über einige Einstellungen, die sich auf die Leistung auswirken können.

Eigenschaft	Beschreibung
CacheEntries	Maximale Anzahl von Einträgen im Regelmodulcache. Der Standardwert ist 32 (dezimal). Empfehlung: Dieser Cache des Regelmoduls wirkt sich auf parallele Richtlinienausführungen aus. Angenommen, es gibt zwei Richtlinien: "Policy1" und "Policy2". Richtlinie1 kann maximal 10 Mal parallel und Policy2 fünfmal parallel ausgeführt werden. Dieser Wert kann auf 15 (10 + 5) festgelegt werden. Wenn eine hohe Anzahl von Richtlinien vorhanden ist und Sie sich nicht sicher sind, wie oft sie parallel ausgeführt werden können, können Sie versuchen, diesen Wert auf die Anzahl der Richtlinien als Startwert festzulegen. Wenn Sie beispielsweise über 200 Richtlinien verfügen, versuchen Sie, diesen Wert auf 200 (dezimal) festzulegen, um festzustellen, ob er sich auf die CPU-Auslastung auswirkt. Wenn <32 Richtlinien vorhanden sind, ist der Standardwert von 32 (Dezimal) in der Regel in Ordnung.
CacheTimeout	Zeit in Sekunden, in der ein Eintrag im Aktualisierungsdienstcache verwaltet wird. Der Standardwert ist 3600 Sekunden (1 Stunde). Wenn nicht innerhalb einer Stunde auf den Cacheeintrag verwiesen wird, wird der Eintrag gelöscht. Empfehlung: Wenn eine Richtlinie regelmäßig aufgerufen wird, sollte der Standardwert von 3600 Sekunden festgelegt werden. Wenn eine Richtlinie weniger häufig aufgerufen wird, z. B. alle 2 Stunden, kann dieser Wert auf >2 Stunden erhöht werden.
CachePruneInterval	Intervall, nach dem die Beschneidungslogik ausgeführt wird. Der Standardwert ist 60 Sekunden (1 Minute). Alle 60 Sekunden sucht der Cache nach abgelaufenen Elementen und bereinigt sie. Dieser Wert wird auch mit dem CacheTimeout-Wert überschritten. Empfehlung: Der Standardwert sollte für die meisten Szenarien in Ordnung sein. Sie kann erhöht werden, wenn Sie eine geringere Anzahl von Elementen im Cache erwarten und der CacheTimeout-Wert groß ist.
PollingInterval	Zeit in Sekunden, in der der Updatedienst die Regelmoduldatenbank auf eine Aktualisierung überprüft. Der Standardwert ist 60 Sekunden (1 Minute). Empfehlung: Wenn die Richtlinien nie oder selten aktualisiert werden, kann dieser Wert erhöht werden. Andernfalls ist der Standardwert ausreichend.
TranslationTimeout	Zeit in Millisekunden, die zum Übersetzen eines Rulesets verwendet werden kann. Der Standardwert ist 60.000 ms (1 Minute). Empfehlung: Wenn es <1 Minute dauert, um ein Ruleset zu übersetzen, hat das Verringern dieses Werts keine Auswirkungen auf die Leistung. Wenn ihre Richtlinienausführung mit einer Ausnahme für ein Übersetzungstimeout fehlschlägt, erhöhen Sie diesen Wert auf jeden Fall. Dies ist eher eine Überprüfung, um sicherzustellen, dass die Richtlinienübersetzung nicht zu viel Zeit in Anspruch nimmt. In der Regel ist der Standardwert ausreichend.
SqlTimeout	Timeoutwert für SQL Befehle, um auf den Regelspeicher zuzugreifen. Der Standardwert ist -1. Mögliche Werte: < 0 : Verwendet den .NET-Standardwert von 30 Sekunden. = 0 – Unbegrenztes Timeout > 0 – Maximale Zeit für eine Abfrage, bevor ein Timeout erreicht wird Empfehlung: In der Regel ist der Standardwert in Ordnung. Wenn Sie erwarten, dass ein SQL Befehl länger ausgeführt wird, kann der Wert erhöht werden.
StaticSupport	Bietet die Möglichkeit, statische Funktionen aufzurufen, die direkt in einer Regel aufgerufen werden können. Der Standardwert ist 0. Mögliche Werte: 0 – Statische Unterstützung ist deaktiviert. Die statische Methode wird nur aufgerufen, wenn eine Instanz der .NET-Klasse bestätigt wird. 1 – Eine Objektinstanz ist nicht erforderlich. Die statische Methode wird aufgerufen, wenn die Regel ausgewertet oder ausgeführt wird. 2 – Eine Objektinstanz ist nicht erforderlich. Die statische Methode wird zum Zeitpunkt der Richtlinienübersetzung aufgerufen, wenn alle Parameter konstant sind. Dies ist eine Leistungsoptimierung, da die statische Methode nur einmal aufgerufen wird, obwohl sie in mehreren Regeln unter Bedingungen verwendet wird. Statische Methoden, die als Aktionen verwendet werden, werden zur Übersetzungszeit nicht ausgeführt, statische Methoden, die als Parameter verwendet werden, können jedoch ausgeführt werden. Empfehlung: Um die statische Unterstützung zu aktivieren, legen Sie diesen Wert mithilfe der obigen Beschreibungen auf 1 oder 2 fest. Hinweis: Dies ist keine Leistungseinstellung, und durch das Ändern dieser Einstellung können vorhandene Richtlinien beschädigt werden.

Diese Einstellungen können in der Registrierung oder in einer .config-Datei festgelegt werden. Die Registrierungseinstellungen sind global für alle Anwendungen, die eine Regelmodulinstanz hosten. Registrierungsspeicherort:

• 32-Bit-Server: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BusinessRules\3.0
• 64-Bit-Server: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\BusinessRules\3.0

Hinweis

Klicken Sie zum Hinzufügen des StaticSupport Schlüssels mit der rechten Maustaste auf den oben genannten Registrierungsschlüssel, zeigen Sie auf "Neu", und wählen Sie dann den DWORD-Wert aus. Geben Sie für Name StaticSupport ein.

Wenn Sie diese Werte in einer Anwendungskonfigurationsdatei festlegen, werden die Werte in der Registrierung überschrieben. Wenn die Richtlinie innerhalb eines IIS-Arbeitsprozesses ausgeführt wird, kann die web.config Datei geändert werden. Wenn die Richtlinie innerhalb einer BizTalk-Orchestrierung ausgeführt wird, kann die BTSNTSvc.exe.config oder BTSNTSvc64.exe.config Datei geändert werden. Es folgt die Sample.config:

<configuration>  
    <configSections>  
        <section name="Microsoft.RuleEngine" type="System.Configuration.SingleTagSectionHandler" />  
    </configSections>  
    <Microsoft.RuleEngine  
        UpdateServiceHost="localhost"  
        UpdateServicePort="3132"  
        UpdateServiceName="RemoteUpdateService"  
        CacheEntries="32"  
        CacheTimeout="3600"  
        PollingInterval="60"  
        TranslationTimeout="3600"  
        CachePruneInterval="60"  
        DatabaseServer="(localhost)"  
        DatabaseName="BizTalkRuleEngineDb"  
        SqlTimeout="-1"  
        StaticSupport="1" />
</configuration>

The Maximum Execution Loop Depth property has a default value of 65536, which determines how many times a rule can be reevaluated

In einem Vorwärtsverkettungsszenario kann die Ausführungsschleife 65.536 Mal ausgeführt werden, bevor eine Ausnahme ausgelöst wird.
Schleifen können auch auftreten, wenn eine oder Update() eine Assert() Funktion ausgeführt wird. Maximum Execution Loop Depth kann an die ungefähre maximale Anzahl von Ausführungsschleifen angepasst werden. In vielen Szenarien empfiehlt es sich, diesen Wert zu verringern, um zu verhindern, dass die Richtlinienausführung in eine Endlosschleife eintritt. Dadurch wird im Wesentlichen die Anzahl der Regelauslösungen, die während der Richtlinienausführung auftreten können, endgültig gestoppt. Wenn Sie beispielsweise die Schleife bei 200 beenden möchten, legen Sie diesen Wert 200 fest.
Nachdem die Richtlinie veröffentlicht wurde, kann die Maximum Execution Loop Depth Eigenschaft nicht mehr geändert werden. Die einzige Option besteht darin, eine neue Version der Richtlinie zu erstellen und den Wert zu ändern. dies kann im Eigenschaftenfenster in Business Rule Composer erfolgen.

Berücksichtigen Sie den Entwurf der Richtlinien, insbesondere mit Assert und Update.

Funktion	Beschreibung
Assert	Die Assert-Funktion fügt eine neue Objektinstanz in den Arbeitsspeicher des Regelmoduls ein, der ausgewertet werden soll. Das Modul verarbeitet jede Instanz gemäß den Bedingungen und Aktionen, die für den Typ der Instanz geschrieben werden, mithilfe der Phasen der Konfliktlösung und -aktion.
Update	Die Update-Funktion fügt ein vorhandenes Objekt basierend auf den neuen Daten und dem Status erneut in den Arbeitsspeicher des Regelmoduls ein, das erneut ausgewertet werden soll. Wenn Sie ein vorhandenes Objekt aktualisieren, werden nur Bedingungen, die die aktualisierte Tatsache verwenden, erneut ausgewertet, und Aktionen werden der Agenda hinzugefügt, wenn diese Bedingungen auf "true" ausgewertet werden. Die Update-Funktion bewirkt, dass alle Regeln, die die aktualisierten Fakten verwenden, erneut ausgewertet werden. Daher können die Update-Funktionsaufrufe teuer sein, insbesondere, wenn eine große Anzahl von Regeln vorhanden ist. Empfehlung: Als Problembehandlungsschritt können Sie das UPDATE entfernen, um die hohe CPU zu beheben. Dies kann unterschiedliche Ergebnisse liefern, aber wenn die CPU-Auslastung korrigiert wird, haben Sie eine gute Vorstellung davon, wo Sie ihre Problembehandlung konzentrieren sollten.

Weitere Informationen zu Assert und Update finden Sie unter dem Link: Effect of Engine Control Functions on Business Rule Execution - Part1

Weitere bewährte Methoden für den Entwurf

• Wenn unterschiedliche Richtlinienobjekte erstellt werden, stellen Sie sicher, dass sie verworfen werden.
• Wenn eine einzelne Anforderung mehrere Threads für die Ausführung generieren kann, achten Sie darauf, den Test mit einer hohen Anzahl von Anforderungen zu laden.
• Die TypedDataTable Bindung wird am besten verwendet, wenn die Größe des Datasets klein ist, in der Regel <10. Die TypedDataTable Bindung ist ein Wrapper zu einem DataTable in ADO.Net, der eine Tabelle mit speicherinternen Daten darstellt. TypedDataTable Objekte sind getrennte Datenobjekte, sodass keine aktive Datenbankverbindung besteht.
• Die DataConnection Bindung wird am besten verwendet, wenn die Größe des Datasets groß ist, in der Regel >= 10. Die DataConnection Bindung ist ein Wrapper zu einem DataSet in ADO.Net, der einen vollständigen Satz von Daten darstellt, einschließlich verwandter Tabellen, Einschränkungen und Beziehungen zwischen den Tabellen. DataConnection Objekte werden von der BRE-Laufzeit geschlossen.