Considerazioni sulle prestazioni quando si utilizza il motore di regole

In questo argomento viene illustrato il modo in cui il motore delle regole viene eseguito in vari scenari e con valori diversi per i parametri di configurazione/ottimizzazione.

Tipi di fatti

Il motore di regole impiega meno tempo ad accedere ai fatti di .NET rispetto ai fatti di XML e del database. Se si ha la possibilità di usare fatti di .NET, XML o di database in un criterio, è consigliabile usare fatti .NET per ottenere prestazioni migliori.

Tabella dati vs. associazione connessione dati

Quando le dimensioni del set di dati sono ridotte (meno di 10 righe), l'associazione TypedDataTable offre prestazioni migliori rispetto all'associazione DataConnection . Quando il set di dati è di grandi dimensioni (maggiore o uguale a circa 10 righe), l'associazione DataConnection offre prestazioni migliori rispetto all'associazione TypedDataTable . È pertanto necessario decidere se utilizzare l'associazione DataConnection o l'associazione TypedDataTable in base alle dimensioni stimate del set di dati.

Raccoglitori di dati

È possibile scrivere un retriever di fatti, ovvero un oggetto che implementa metodi standard e li usa in genere per fornire fatti di lungo termine e che cambiano lentamente al motore di regole prima dell'esecuzione dei criteri. Il motore memorizza nella cache questi fatti e li usa 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 recuperatore di fatti che invii il fatto la prima volta e 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 il criterio implementa il comportamento di concatenamento in avanti tramite le 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 che Rule1 viene attivato e aggiornato il valore. Viceversa, se Rule2 ha una priorità più alta, può essere attivato una volta, e quindi attivato nuovamente dopo che Rule1 è stato attivato e ha aggiornato il fatto che Rule2 viene utilizzato in una condizione. Questo potrebbe produrre o meno i risultati corretti, ma l'attivazione due volte ha un impatto sulle prestazioni rispetto all'attivazione una sola volta.

Aggiornare le chiamate

La funzione Update aggiorna un fatto presente nella memoria di lavoro del motore delle regole e determina la rivalutazione di tutte le regole che usano il fatto aggiornato in condizioni. Le chiamate di funzione di aggiornamento possono essere costose, soprattutto se molte regole devono essere rivalutate a causa dell'aggiornamento dei fatti. In alcune situazioni è possibile evitare di dover rivalutare le regole. 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 e Rule2 vengono valutate due volte, una volta prima della chiamata di aggiornamento e una volta dopo la chiamata di aggiornamento .

È invece 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 Update non viene chiamato se l'importo è minore o uguale a 5. Pertanto, tutte le regole ad eccezione di Rule1 e Rule2 vengono valutate due volte solo se il valore del campo Amount è maggiore di 5.

Uso di operatori logici OR

Il motore delle regole è ottimizzato per l'esecuzione di operatori AND logici e ricostruisce la regola analizzata in un formato normale disgiuntivo in modo che l'operatore OR venga usato solo al livello superiore. L'uso di un numero crescente di operatori logici OR nelle condizioni crea ulteriori permutazioni che espandono la rete di valutazione del motore di regole e potrebbe richiedere molto tempo al motore di regole per normalizzare la regola. L'elenco seguente contiene possibili soluzioni alternative per questo problema.

• Modificare la regola in modo che sia in forma normale disgiuntiva in modo che l'operatore OR sia solo al livello superiore. Si noti che lo sviluppo di una regola in forma normale disgiuntiva in Business Rule Composer può essere complicato. È consigliabile prendere in considerazione la creazione della regola a livello di codice.

• Sviluppare un componente helper che esegue le operazioni OR e restituisce un valore booleano e usare il componente nella regola.

• Prendere in considerazione la suddivisione della regola in più regole e verificare la presenza di un flag impostato da una regola eseguita in precedenza o usare un oggetto asserzionato da una regola eseguita in precedenza, come illustrato negli esempi seguenti:

  • Regola 1: IF (a == 1 OR a == 3) THEN b = true

    Regola 2: se (b == true) THEN ...

  • Regola 1: IF (a == 1 OR a == 3) THEN assert(new c())

    Regola 2: IF (c.flag == true) THEN ...

Impostazioni di memorizzazione nella cache

Il motore di regole usa due cache. Il primo si trova nel servizio di aggiornamento e il secondo si trova in 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 viene richiamata di nuovo la stessa politica, il processo BizTalk riutilizza l'oggetto politica dalla cache, se disponibile.

Analogamente, se il processo BizTalk richiede le informazioni su un criterio dal servizio di aggiornamento, il servizio di aggiornamento cerca innanzitutto le informazioni sui criteri nella cache. Il servizio di aggiornamento controlla anche ogni 60 secondi (un minuto) per verificare 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 di CacheEntries è il numero massimo di voci nella cache. Il valore predefinito di CacheEntries è 32. È possibile aumentare il valore del parametro CacheEntries per migliorare le prestazioni in alcuni casi. Si supponga, ad esempio, di usare ripetutamente 40 criteri. In questo caso, è possibile aumentare il valore di CacheEntries a 40 per migliorare le prestazioni. In questo modo il servizio di aggiornamento può memorizzare nella cache i dettagli di un massimo di 40 criteri in memoria. Inoltre, il servizio BizTalk potrebbe memorizzare nella cache fino a 40 istanze di criteri in memoria. Nella cache del servizio BizTalk potrebbero essere presenti più istanze di un criterio.

Il valore di CacheTimeout è il tempo, espresso in secondi, per l'espulsione delle voci dalla cache del servizio di aggiornamento. In altre parole, il valore CacheTimeout indica per quanto tempo una voce della cache per un criterio viene mantenuta nella cache se non vi sono riferimenti. Il valore predefinito di CacheTimeout è 3600 secondi (un'ora). Ciò significa che, se la voce della cache non viene consultata entro un'ora, viene eliminata. In alcuni casi, è possibile aumentare il valore CacheTimeout per migliorare le prestazioni. Si supponga, ad esempio, che il criterio venga richiamato ogni due ore. È possibile migliorare le prestazioni dell'esecuzione dei criteri aumentando il valore del parametro CacheTimeout a un valore maggiore di due ore.

Il parametro PollingInterval per il motore regole definisce il tempo in secondi per l'intervallo in cui il servizio di aggiornamento controlla la presenza di aggiornamenti nel database del motore di regole. Il valore predefinito per il parametro PollingInterval è 60 secondi (un minuto). Se si sa che i criteri non vengono aggiornati affatto o vengono aggiornati raramente, è possibile aumentare questo valore per migliorare le prestazioni.

SideEffects, proprietà

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.