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 tener acceso a los hechos de .NET en comparación con el tiempo necesario para acceder a los hechos xml y de base de datos. Si tiene la opción de usar hechos de .NET o XML o de 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 debe 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 regla

La configuración de prioridad de una regla puede oscilar en cualquier lado de 0, con números mayores con mayor prioridad. Las acciones se ejecutan en orden de la prioridad más alta a la prioridad más baja. Cuando la directiva implementa el comportamiento de encadenamiento de reenvío mediante llamadas Assert/Update , el encadenamiento se puede optimizar mediante la configuración de prioridad. Por ejemplo, supongamos que Rule2 tiene una dependencia de un valor establecido por Rule1. Dar 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 asigna 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, dar a Rule1 una prioridad más alta en este escenario proporcionará un mejor rendimiento.

Actualizar llamadas

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

Regla1:

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

Regla 2:

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 Cantidad , 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 Amount es mayor que 5 y no se llama a la función Update si el valor de Amount es menor o igual que 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 cada vez mayor de operadores lógicos O en las condiciones crea permutaciones adicionales que expanden la red de análisis del motor de reglas. Desde el punto de vista del rendimiento, será mejor dividir las condiciones en reglas atómicas que no contengan operadores lógicos O .

Configuración de almacenamiento en caché

El motor de reglas usa dos memorias caché. El servicio de actualización usa el primero 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 memoria caché si está disponible. Cada 60 segundos, el servicio de actualización también comprueba si ha habido alguna actualización de la directiva en la base de datos. Si hay alguna actualización, 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. Se pueden especificar los valores de estos parámetros tanto en el Registro como 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 los detalles de la memoria caché de hasta 40 directivas en memoria.

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 3600 segundos o 1 hora. Esto 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 con poca frecuencia, puede 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, de la columna o del miembro enlazados se ha almacenado 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 obtiene acceso por segunda vez (o más tarde dentro de la directiva) a un campo de un documento XML o a una columna de una tabla de una base de datos, su valor se recupera desde la caché. Sin embargo, cuando se obtiene acceso por segunda vez (o posteriormente) a un miembro de un objeto .NET, el valor se recupera desde el objeto .NET y no desde la 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. Tan solo se puede hacer esto mediante programación. La herramienta Compositor de reglas de negocios no expone la propiedad SideEffects .

Instancias y selectividad

Las clases XmlDocumentBinding, ClassBinding y DatabaseBinding tienen dos propiedades: Instances y Selectivity. El valor de Instances corresponde al número esperado de instancias de la clase en la memoria de trabajo. El valor de Selectivity es el porcentaje de las instancias de clase que pasarán correctamente las condiciones de la regla. El motor de reglas usa estos valores para optimizar la evaluación de condiciones de modo que se utilice primero el menor número de instancias posible en las evaluaciones de condiciones y posteriormente se usen 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. Del mismo modo, si tiene conocimiento previo del porcentaje de estos objetos que pasan las condiciones, establecer la propiedad Selectivity en ese valor mejoraría el rendimiento. Tan solo se pueden establecer los valores de estos parámetros mediante programación. La herramienta Compositor de reglas de negocio no los expone.

Consulte también

Optimización del rendimiento de BizTalk Server