Ottimizzazione delle prestazioni di Motore regole di business
Quando si implementa il motore regole business (BRE) in una soluzione di BizTalk Server, è necessario considerare i fattori seguenti:
Tipi di fatti
Il motore regole richiede meno tempo per accedere ai fatti .NET rispetto al tempo necessario per accedere ai fatti XML e del database. Se si ha la possibilità di usare i fatti di .NET o XML o di database in un criterio, è consigliabile usare i fatti .NET per migliorare le prestazioni.
Tabella dati e connessione dati
Quando le dimensioni del set di dati sono ridotte (< 10 o così via), l'associazione TypedDataTable offre prestazioni migliori rispetto all'associazione DataConnection . Tuttavia, l'associazione DataConnection offre prestazioni migliori rispetto all'associazione TypedDataTable quando il set di dati è di grandi dimensioni (maggiore o uguale a 10 righe circa). È pertanto necessario decidere se utilizzare l'associazione DataConnection o l'associazione TypedDataTable in base alle dimensioni stimate del set di dati.
Recuperatori di fatti
Un retriever dei fatti implementa metodi standard che in genere vengono usati per fornire fatti a lungo termine e a cambiare lentamente il motore delle regole prima dell'esecuzione di un criterio. Il motore memorizza questi fact nella cache e li utilizza su più cicli di esecuzione. Anziché inviare un fatto statico o abbastanza statico ogni volta che si richiama il motore delle regole, è necessario creare un retriever dei fatti che invia il fatto per la prima volta e quindi aggiorna il fatto in memoria solo quando necessario.
Priorità delle regole
L'impostazione di priorità per una regola può variare su entrambi i lati di 0, con numeri più grandi con priorità più alta. Le azioni vengono eseguite in ordine dalla priorità più alta alla priorità più bassa. Quando il criterio implementa il comportamento di forward chaining tramite chiamate Assert/Update , il concatenamento può essere ottimizzato usando l'impostazione di priorità. Si supponga, ad esempio, che Rule2 abbia una dipendenza da un valore impostato da Rule1. Assegnando a Rule1 una priorità più alta significa che Rule2 verrà eseguito solo dopo l'attivazione di Rule1 e l'aggiornamento del valore. Viceversa, se Rule2 ha una priorità più alta, potrebbe essere attivato una sola volta e quindi generato nuovamente dopo l'attivazione di Rule1 e aggiornare il fatto che Rule2 stia usando una condizione. Anche se ciò può fornire un risultato corretto, assegnando a Rule1 una priorità più alta in questo scenario offrirà prestazioni migliori.
Aggiornare le chiamate
La funzione Update determina la rivalutazione di tutte le regole che usano i fatti aggiornati. Le chiamate di funzione di aggiornamento possono essere costose soprattutto se un set elevato di regole viene rivalutato durante l'aggiornamento dei fatti. Esistono situazioni in cui questo comportamento può essere evitato. Si considerino ad esempio le regole seguenti.
Regola1:
IF PurchaseOrder.Amount > 5
THEN StatusObj.Flag = true; Update(StatusObj)
Regola2:
IF PurchaseOrder.Amount <= 5
THEN StatusObj.Flag = false; Update(StatusObj)
Tutte le regole rimanenti del criterio usano StatusObj.Flag nelle relative condizioni. Pertanto, quando Update viene chiamato sull'oggetto StatusObj , tutte le regole verranno rivalutate. Indipendentemente dal valore del campo Amount , tutte le regole ad eccezione di Rule1 o Rule2 vengono valutate due volte, una volta prima della chiamata update e una volta dopo la chiamata Di aggiornamento .
Per ridurre il sovraccarico associato, è possibile impostare il valore del campo del flagsu false prima di richiamare il criterio e quindi usare solo Rule1 nel criterio per impostare il flag. In questo caso, update verrà chiamato solo se il valore del campo Amount è maggiore di 5 e la funzione Update non viene chiamata se il valore di Amount è minore o uguale a 5. Pertanto, tutte le regole ad eccezione di Rule1 o Rule2 vengono valutate due volte solo se il valore del campo Amount è maggiore di 5.
Utilizzo degli operatori OR logici
L'uso di un numero crescente di operatori OR logici nelle condizioni crea ulteriori permutazioni che espandono l'ambito di analisi del Motore regole di business. Dal punto di vista delle prestazioni, è preferibile suddividere le condizioni in regole atomiche che non contengono operatori OR logici.
Impostazioni di memorizzazione nella cache
Il motore regole usa due cache. Il primo viene usato dal servizio di aggiornamento e il secondo viene usato da ogni processo BizTalk. La prima volta che viene usato un criterio, il processo BizTalk richiede le informazioni sui criteri dal servizio di aggiornamento. Il servizio di aggiornamento recupera le informazioni sui criteri dal database del motore regole, lo memorizza nella cache e restituisce le informazioni al processo BizTalk. Il processo BizTalk crea un oggetto criteri basato su tali informazioni e archivia l'oggetto criteri in una cache quando l'istanza del motore regole associata completa l'esecuzione dei criteri. Quando lo stesso criterio viene richiamato nuovamente, il processo BizTalk riutilizza l'oggetto criteri dalla cache, se disponibile. Analogamente, se il processo BizTalk richiede informazioni su un criterio dal servizio di aggiornamento, il servizio di aggiornamento cerca le informazioni sui criteri nella cache, se disponibile. Ogni 60 secondi, il servizio di aggiornamento controlla anche se sono stati apportati aggiornamenti ai criteri nel database. Se sono presenti aggiornamenti, il servizio di aggiornamento recupera le informazioni e memorizza nella cache le informazioni aggiornate.
Esistono tre parametri di ottimizzazione per il motore regole correlati a queste cache: CacheEntries, CacheTimeout e PollingInterval. I valori di tali parametri possono essere specificati nel Registro di sistema o in un file di configurazione. Il valore del parametro CacheEntries è il numero massimo di voci nella cache ed è impostato su un valore pari a 32 per impostazione predefinita. È possibile aumentare il valore del parametro CacheEntries per migliorare le prestazioni in determinati scenari. Si supponga, ad esempio, di usare ripetutamente 40 criteri; È possibile aumentare il valore del parametro CacheEntries a 40 per migliorare le prestazioni. In questo modo il servizio di aggiornamento può mantenere i dettagli della cache di un massimo di 40 criteri in memoria.
Il valore di CacheTimeout è il tempo in secondi in cui una voce viene mantenuta nella cache del servizio di aggiornamento. In altre parole, il valore CacheTimeout indica per quanto tempo viene mantenuta una voce della cache per un criterio nella cache senza farvi riferimento. Il valore predefinito del parametro CacheTimeout è 3600 secondi o 1 ora. Ciò significa che se la voce della cache non viene fatto riferimento entro un'ora, la voce viene eliminata. In alcuni casi, può essere utile aumentare il valore del parametro CacheTimeout per migliorare le prestazioni. Ad esempio, se un criterio viene richiamato ogni due ore, le prestazioni dell'esecuzione dei criteri verranno migliorate aumentando il parametro CacheTimeout a un valore superiore a due ore.
Il parametro PollingInterval del motore regole definisce il tempo in secondi per il servizio di aggiornamento per controllare la presenza di aggiornamenti nel database del motore regole. Il valore predefinito per il parametro PollingInterval è 60 secondi. Se si è certi che i criteri non vengono aggiornati affatto o vengono aggiornati raramente, è possibile modificare questo parametro impostando un valore superiore per migliorare le prestazioni.
Proprietà SideEffects
Le classi ClassMemberBinding, DatabaseColumnBinding e XmlDocumentFieldBinding hanno una proprietà denominata SideEffects. Tale proprietà determina se il valore del campo, del membro o della colonna associata viene memorizzato nella cache. Il valore predefinito della proprietà SideEffects nelle classi DatabaseColumnBinding e XmlDocumentFieldBinding è false. Il valore predefinito della proprietà SideEffects nella classe ClassMemberBinding è true. Quando si accede a un campo di un documento XML o di una colonna di una tabella di database per la seconda volta o successivamente all'interno del criterio, il relativo valore viene pertanto recuperato dalla cache. Se, tuttavia, si accede a un membro di un oggetto .NET per la seconda volta o successivamente, il valore viene recuperato dall'oggetto .NET e non dalla cache. L'impostazione della proprietà SideEffects di una classe .NETMemberBinding su false migliorerà le prestazioni perché il valore del campo viene recuperato dalla cache dalla seconda volta in poi. È possibile eseguire questa operazione solo a livello di codice. Lo strumento Business Rule Composer non espone la proprietà SideEffects .
Istanze e selettività
Le classi XmlDocumentBinding, ClassBinding e DatabaseBinding hanno due proprietà: Instances e Selectivity. Il valore di Instances indica il numero previsto di istanze della classe nella memoria di lavoro. Il valore di Selectivity è la percentuale delle istanze della classe che passeranno correttamente le condizioni della regola. Il Motore regole di business utilizza tali valori per ottimizzare la valutazione delle condizioni in modo che venga utilizzato prima il numero di istanze minore possibile, per poi passare alle istanze rimanenti. Se si conosce in precedenza il numero di istanze dell'oggetto, l'impostazione della proprietà Instances su tale valore migliorerebbe le prestazioni. Analogamente, se si conosce in precedenza la percentuale di questi oggetti che passano le condizioni, l'impostazione della proprietà Selectivity su tale valore migliorerebbe le prestazioni. È possibile impostare i valori di questi parametri solo a livello di codice. Lo strumento Creazione regole di business non li espone.