Ottimizzazione delle prestazioni del motore delle regole aziendali

Quando si implementa il motore regole business in una soluzione BizTalk Server, è necessario considerare i fattori seguenti:

Tipi di fatti

Il motore di regole richiede meno tempo per accedere ai fatti .NET rispetto al tempo necessario per accedere ai fatti XML e ai fatti del database. Se hai la possibilità di usare fatti .NET, XML o di database in una policy, dovresti considerare l'uso di 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.

Ricercatori di informazioni

Un retriever dei fatti implementa metodi standard che vengono in genere usati per fornire fatti a lungo termine e che cambiano lentamente al motore di regole prima dell'esecuzione di una politica. Il motore memorizza nella cache questi fatti e li usa su più cicli di esecuzione. Anziché inviare un fatto statico o relativamente statico ogni volta che richiamo il motore delle regole, dovresti creare un meccanismo di recupero dei fatti che invii il fatto per la prima volta e quindi aggiorni 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 la politica implementa il comportamento di concatenamento in avanti tramite le chiamate Assert/Update, il concatenamento può essere ottimizzato usando l'uso delle impostazioni di priorità. Si supponga, ad esempio, che Rule2 abbia una dipendenza da un valore impostato da Rule1. Dare a Rule1 una priorità più alta significa che Rule2 verrà eseguito solo dopo che Rule1 sia stato attivato e aggiornato il valore. Viceversa, se Rule2 avesse una priorità più alta, potrebbe scattare una volta, e poi scattare di nuovo dopo che Rule1 si è verificata e aggiornare il fatto che Rule2 utilizza una condizione. Anche se questo 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 ampio insieme di regole venga rivalutato durante l'aggiornamento dei fatti. In alcune situazioni è possibile evitare questo comportamento. 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 di aggiornamento e una volta dopo la chiamata di aggiornamento .

Per ridurre il sovraccarico associato, è possibile impostare il valore del campo flagsu false prima di richiamare il criterio e quindi usare solo Rule1 nei criteri per impostare il flag. In questo caso, Update viene 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 la rete di analisi del motore di regole. 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 delle 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 di 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 di regole associata completa l'esecuzione dei criteri. Quando lo stesso criterio viene richiamato di nuovo, il processo BizTalk riutilizza l'oggetto criterio 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. È possibile specificare i valori per questi parametri 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 una voce della cache relativa a una policy viene mantenuta nella cache senza essere consultata. Il valore predefinito del parametro CacheTimeout è 3600 secondi o 1 ora. Ciò significa che se all'elemento della cache non viene fatto riferimento entro un'ora, l'elemento viene eliminato. 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 di regole. Il valore predefinito per il parametro PollingInterval è 60 secondi. Se si sa che i criteri non vengono aggiornati affatto o vengono aggiornati raramente, è possibile modificare questo parametro in un valore superiore per migliorare le prestazioni.

Proprietà SideEffects

Le classi ClassMemberBinding, DatabaseColumnBinding e XmlDocumentFieldBinding hanno una proprietà denominata SideEffects. Questa proprietà determina se il valore del campo associato, del membro o della colonna 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. Pertanto, quando si accede a un campo di un documento XML o di una colonna di una tabella di database per la seconda volta o successiva all'interno dei criteri, il relativo valore viene recuperato dalla cache. Tuttavia, quando si accede a un membro di un oggetto .NET per la seconda volta o versione successiva, il valore viene recuperato dall'oggetto .NET e non dalla cache. L'impostazione della proprietà SideEffects di un oggetto ClassMemberBinding .NET 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 è 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 delle regole usa questi valori per ottimizzare la valutazione della condizione in modo che le istanze più minime possibili vengano usate prima nelle valutazioni delle condizioni e quindi vengono usate le istanze rimanenti. Se si ha una conoscenza precedente del numero di istanze dell'oggetto, impostare la proprietà Instances su tale valore migliorerebbe le prestazioni. Analogamente, se si ha una conoscenza precedente della percentuale di questi oggetti che passano le condizioni, l'impostazione della proprietà Selectivity su tale valore migliorerebbe le prestazioni. È possibile impostare valori solo per questi parametri a livello di codice. Lo strumento Business Rule Composer non li espone.

Vedere anche

Ottimizzazione delle prestazioni di BizTalk Server