Optimización del rendimiento del motor de reglas de negocio (BRE)

Se deben tener en cuenta los siguientes factores al implementar el motor de reglas de negocios (BRE) en una solución de BizTalk Server:

Tipos de hechos

El motor de reglas tarda menos tiempo en obtener acceso a los hechos de .NET en comparación con el tiempo que tarda en acceder a los hechos xml y de base de datos. Si tiene la opción de usar hechos de .NET o XML o base de datos en una directiva, debe considerar el uso de hechos de .NET para mejorar el rendimiento.

Tabla de datos frente a conexión de datos

Cuando el tamaño del conjunto de datos es pequeño (< 10 o así), el enlace TypedDataTable proporciona un mejor rendimiento que el enlace DataConnection . Sin embargo, el enlace DataConnection funciona mejor que el enlace TypedDataTable cuando el conjunto de datos es grande (mayor o igual que 10 filas aproximadamente). Por lo tanto, debe decidir si desea usar el enlace DataConnection o el enlace TypedDataTable en función del tamaño estimado del conjunto de datos.

Recuperadores de hechos

Un recuperador de hechos implementa métodos estándar que normalmente se usan para proporcionar hechos a largo plazo y que cambian lentamente al motor de reglas antes de ejecutar una directiva. El motor almacena estos datos en caché y los utiliza en varios ciclos de ejecución. En lugar de enviar un hecho estático o bastante estático cada vez que invoque el motor de reglas, debe crear un recuperador de hechos que envíe el hecho por primera vez y, a continuación, actualice el hecho en memoria solo cuando sea necesario.

Prioridad de las reglas

La configuración de prioridad de una regla puede oscilar a ambos lados de 0, donde los números mayores tienen más prioridad. Las acciones se ejecutan en orden de la prioridad más alta a la prioridad más baja. Cuando la política implementa el comportamiento de encadenamiento hacia adelante mediante las llamadas Assert/Update, el encadenamiento se puede optimizar mediante la configuración de la prioridad. Por ejemplo, supongamos que Rule2 tiene una dependencia de un valor establecido por Rule1. Conceder a Rule1 una prioridad más alta significa que Rule2 solo se ejecutará después de que Rule1 se active y actualice el valor. Por el contrario, si a Rule2 se le dio una prioridad más alta, podría activarse una vez y, a continuación, volver a activarse después de que Rule1 se active y actualice el hecho de que Rule2 usa una condición. Aunque esto puede proporcionar un resultado correcto, proporcionar a Rule1 una prioridad más alta en este escenario proporcionará un mejor rendimiento.

Llamadas a Update

La función Update hace que todas las reglas que usan los hechos actualizados se vuelvan a evaluar. Las llamadas a función de actualización pueden ser onerosas, especialmente si se vuelve a evaluar un gran conjunto de reglas cuando se actualizan los hechos. Hay situaciones en las que se puede evitar este comportamiento. Por ejemplo, tenga en cuenta las siguientes reglas.

Regla1:

IF PurchaseOrder.Amount > 5   
THEN StatusObj.Flag = true; Update(StatusObj)  

Rule2:

IF PurchaseOrder.Amount <= 5   
THEN StatusObj.Flag = false; Update(StatusObj)  

Todas las reglas restantes de la directiva usan StatusObj.Flag en sus condiciones. Por lo tanto, cuando se llama a Update en el objeto StatusObj , se volverán a evaluar todas las reglas. Sea cual sea el valor del campo Importe , todas las reglas excepto Rule1 o Rule2 se evalúan dos veces, una vez antes de la llamada a Update y una vez después de la llamada a Update .

Para mitigar la sobrecarga asociada, puede establecer el valor del campo de marca en false antes de invocar la directiva y, a continuación, usar solo Rule1 en la directiva para establecer la marca. En este caso, solo se llamaría a Update si el valor del campo Importe es mayor que 5, y no se llamaría a la función Update si el valor de Importe es menor o igual a 5. Por lo tanto, todas las reglas excepto Rule1 o Rule2 solo se evalúan dos veces si el valor del campo Cantidad es mayor que 5.

Uso de operadores OR lógicos

El uso de un número creciente de operadores OR lógicos en condiciones crea permutaciones adicionales que expanden la red de análisis del motor de reglas. Desde el punto de vista del rendimiento, es mejor dividir las condiciones en reglas atómicas que no contienen operadores OR lógicos.

Configuración de almacenamiento en caché

El motor de reglas usa dos cachés. El primero lo usa el servicio de actualización y el segundo lo usa cada proceso de BizTalk. La primera vez que se usa una directiva, el proceso de BizTalk solicita la información de directiva del servicio de actualización. El servicio de actualización recupera la información de directiva de la base de datos del motor de reglas, la almacena en caché y devuelve la información al proceso de BizTalk. El proceso de BizTalk crea un objeto de directiva basado en esa información y almacena el objeto de directiva en una memoria caché cuando la instancia del motor de reglas asociada completa la ejecución de la directiva. Cuando se invoca de nuevo la misma directiva, el proceso de BizTalk reutiliza el objeto de directiva de la memoria caché si hay uno disponible. Del mismo modo, si el proceso de BizTalk solicita información sobre una directiva del servicio de actualización, el servicio de actualización busca la información de directiva en su caché si está disponible. Cada 60 segundos, el servicio de actualización también comprueba si se han producido actualizaciones en la directiva de la base de datos. Si hay actualizaciones, el servicio de actualización recupera la información y almacena en caché la información actualizada.

Hay tres parámetros de optimización para el motor de reglas relacionados con estas memorias caché: CacheEntries, CacheTimeout y PollingInterval. Puede especificar los valores de estos parámetros en el Registro o en un archivo de configuración. El valor del parámetro CacheEntries es el número máximo de entradas de la memoria caché y se establece en un valor de 32 de forma predeterminada. Es posible que desee aumentar el valor del parámetro CacheEntries para mejorar el rendimiento en determinados escenarios. Por ejemplo, supongamos que usa 40 directivas repetidamente; puede aumentar el valor del parámetro CacheEntries a 40 para mejorar el rendimiento. Esto permitiría al servicio de actualización mantener en memoria caché los detalles de hasta 40 políticas.

El valor de CacheTimeout es el tiempo en segundos que se mantiene una entrada en la caché del servicio de actualización. En otras palabras, el valor CacheTimeout hace referencia a cuánto tiempo se mantiene una entrada de caché para una directiva en la memoria caché sin que se haga referencia a ella. El valor predeterminado del parámetro CacheTimeout es de 3600 segundos o 1 hora. Significa que si no se hace referencia a la entrada de caché en un plazo de una hora, se elimina la entrada. En algunos casos, puede ser beneficioso aumentar el valor del parámetro CacheTimeout para mejorar el rendimiento. Por ejemplo, si se invoca una directiva cada dos horas, el rendimiento de la ejecución de la directiva se mejoraría aumentando el parámetro CacheTimeout a un valor superior a dos horas.

El parámetro PollingInterval del motor de reglas define el tiempo en segundos para que el servicio de actualización compruebe si hay actualizaciones en la base de datos del motor de reglas. El valor predeterminado para el parámetro PollingInterval es de 60 segundos. Si sabe que las directivas no se actualizan en absoluto o se actualizan rara vez, podría cambiar este parámetro a un valor mayor para mejorar el rendimiento.

SideEffects (propiedad)

Las clases ClassMemberBinding, DatabaseColumnBinding y XmlDocumentFieldBinding tienen una propiedad denominada SideEffects. Esta propiedad determina si el valor del campo enlazado, miembro o columna se almacena en caché. El valor predeterminado de la propiedad SideEffects en las clases DatabaseColumnBinding y XmlDocumentFieldBinding es false. El valor predeterminado de la propiedad SideEffects de la clase ClassMemberBinding es true. Por lo tanto, cuando se accede a un campo de un documento XML o una columna de una tabla de base de datos por segunda vez o posterior dentro de la directiva, su valor se recupera de la memoria caché. Sin embargo, cuando se accede a un miembro de un objeto .NET por segunda vez o posterior, el valor se recupera del objeto .NET y no de la memoria caché. Establecer la propiedad SideEffects de un classMemberBinding de .NET en false mejorará el rendimiento porque el valor del campo se recupera de la memoria caché desde la segunda vez. Solo puede hacerlo mediante programación. La herramienta Business Rule Composer no expone la propiedad SideEffects .

Instancias y selectividad

Las clases XmlDocumentBinding, ClassBinding y DatabaseBinding tienen dos propiedades: Instances y Selectivity. El valor de Instances es el número esperado de instancias de la clase en memoria de trabajo. El valor de Selectivity es el porcentaje de las instancias de clase que pasarán correctamente las condiciones de regla. El motor de reglas utiliza estos valores para optimizar la evaluación de la condición, priorizando el uso de la menor cantidad de instancias posibles en las evaluaciones de condiciones primero, y luego utilizando las instancias restantes. Si tiene conocimiento previo del número de instancias del objeto, establecer la propiedad Instances en ese valor mejoraría el rendimiento. De forma similar, si tiene conocimiento previo del porcentaje de estos objetos que pasan las condiciones, establecer la propiedad Selectivity en ese valor mejoraría el rendimiento. Solo puede establecer valores para estos parámetros mediante programación. La herramienta Business Rule Composer no las expone.

Véase también

Optimización del rendimiento de BizTalk Server