CPU alta al ejecutar una directiva BRE
En este artículo se proporciona información que cuando se usa una directiva de motor de reglas de negocio (BRE) dentro de una orquestación o se usa el marco de reglas empresariales para ejecutar una directiva BRE, el proceso que ejecuta la directiva puede experimentar cpu alta.
Versión del producto original: BizTalk Server
Número KB original: 2498797
Ejemplo para el escenario de CPU alta
Hay un ejemplo de que un servicio web ASMX puede usar la Microsoft.RuleEngine.Policy clase para ejecutar una directiva BRE. En este escenario, hay un rendimiento lento y el w3wp.exe está usando cpu alta. Si la directiva se ejecuta dentro de una orquestación, btsntsvc.exe o btsntsvc64.exe proceso usará cpu alta.
BRE tiene algunas opciones de configuración que pueden afectar al rendimiento
| Propiedad | Descripción |
|---|---|
| CacheEntries | Número máximo de entradas en la memoria caché del motor de reglas. El valor predeterminado es 32 (decimal). Recomendación: Esta caché del motor de reglas afecta a las ejecuciones de directivas paralelas. Por ejemplo, supongamos que hay dos directivas: Policy1 y Policy2. Policy1 se puede ejecutar un máximo de 10 veces en paralelo y Policy2 se puede ejecutar cinco veces en paralelo. Este valor se puede establecer en 15 (10 + 5). Si hay un gran número de directivas y no está seguro de cuántas veces se podrían ejecutar en paralelo, puede intentar establecer este valor en el número de directivas como valor inicial. Por ejemplo, si tiene 200 directivas, intente establecer este valor en 200 (decimal) para ver si afecta al uso de la CPU. Si hay <32 directivas, el valor predeterminado de 32 (decimal) suele estar bien. |
| CacheTimeout | Tiempo en segundos en que se mantiene una entrada en la memoria caché del servicio de actualización. El valor predeterminado es 3600 segundos (1 hora). Si no se hace referencia a la entrada de caché en 1 hora, se elimina la entrada. Recomendación: si se invoca una directiva con regularidad, se debe establecer el valor predeterminado de 3600 segundos. Si se invoca una directiva con menos frecuencia, como cada 2 horas, este valor se puede aumentar a >2 horas. |
| CachePruneInterval | Intervalo tras el cual se ejecuta la lógica de poda. El valor predeterminado es 60 segundos (1 minuto). Cada 60 segundos, la memoria caché comprueba los elementos que han expirado y los limpia. Este valor también se cruza con el valor CacheTimeout. Recomendación: El valor predeterminado debe estar bien en la mayoría de los escenarios. Se puede aumentar si se espera menos número de elementos en la memoria caché y el valor de CacheTimeout es grande. |
| PollingInterval | Tiempo en segundos en que el servicio de actualización comprueba si hay una actualización en la base de datos del motor de reglas. El valor predeterminado es 60 segundos (1 minuto). Recomendación: si las directivas nunca o rara vez se actualizan, este valor puede aumentarse. De lo contrario, el valor predeterminado es suficiente. |
| TranslationTimeout | Tiempo en milisegundos que se puede usar para traducir un conjunto de reglas. El valor predeterminado es 60 000 ms (1 minuto). Recomendación: si se tarda <1 minuto para traducir un conjunto de reglas, la disminución de este valor no tiene ningún impacto en el rendimiento. Si se produce un error en la ejecución de la directiva con una excepción de tiempo de espera de traducción, aumente definitivamente este valor. Esto es más que una comprobación para garantizar que la traducción de directivas no tarde demasiado tiempo. Normalmente, el valor predeterminado es suficiente. |
| SqlTimeout | Valor de tiempo de espera SQL comandos para obtener acceso al almacén de reglas. El valor predeterminado es -1. Posibles valores: < 0: usa el valor predeterminado de .NET de 30 segundos = 0: tiempo de espera ilimitado > 0: tiempo máximo para una consulta antes de que se abate el tiempo de espera Recomendación: Normalmente, el valor predeterminado es bueno. Si espera que un comando SQL ejecute más tiempo, el valor puede aumentarse. |
| StaticSupport | Proporciona la capacidad de invocar funciones estáticas a las que se puede llamar directamente en una regla. El valor predeterminado es 0. Posibles valores: 0: la compatibilidad estática está deshabilitada. Se llama al método estático solo cuando se afirma una instancia de la clase .NET. 1: no se requiere una instancia de objeto. Se llama al método estático cuando se evalúa o ejecuta la regla. 2: no se requiere una instancia de objeto. Se llama al método estático en el tiempo de traducción de la directiva si todos los parámetros son constantes. Se trata de una optimización del rendimiento porque se llama al método estático solo una vez aunque se usa en varias reglas en condiciones. Los métodos estáticos usados como acciones no se ejecutarán en el momento de la traducción, pero se pueden ejecutar métodos estáticos usados como parámetros. Recomendación: Para habilitar la compatibilidad estática, establezca este valor en 1 o 2 con las descripciones anteriores. Nota: Esta no es una configuración de rendimiento y cambiarla puede interrumpir las directivas existentes. |
Esta configuración se puede establecer en el Registro o en un .config archivo. La configuración del Registro es global para todas las aplicaciones que hospedan una instancia del motor de reglas. Ubicación del Registro:
- Servidor de 32 bits:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BusinessRules\3.0 - Servidor de 64 bits:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\BusinessRules\3.0
Nota
Para agregar la clave StaticSupport , haga clic con el botón secundario en la clave del Registro anterior, elija Nuevo y, a continuación, seleccione Valor DWORD . En Nombre, escriba StaticSupport.
Al establecer estos valores en un archivo de configuración de aplicación, se invalidarán los valores del Registro. Si la directiva se ejecuta dentro de un proceso de trabajo de IIS, se puede modificarweb.config archivo. Si la directiva se ejecuta dentro de una orquestación de BizTalk, el archivo BTSNTSvc.exe.config o BTSNTSvc64.exe.config puede modificarse. A continuación se muestra Sample.config:
<configuration>
<configSections>
<section name="Microsoft.RuleEngine" type="System.Configuration.SingleTagSectionHandler" />
</configSections>
<Microsoft.RuleEngine
UpdateServiceHost="localhost"
UpdateServicePort="3132"
UpdateServiceName="RemoteUpdateService"
CacheEntries="32"
CacheTimeout="3600"
PollingInterval="60"
TranslationTimeout="3600"
CachePruneInterval="60"
DatabaseServer="(localhost)"
DatabaseName="BizTalkRuleEngineDb"
SqlTimeout="-1"
StaticSupport="1" />
</configuration>
La propiedad Maximum Execution Loop Depth tiene un valor predeterminado de 65536, que determina cuántas veces se puede reevaluar una regla
En un escenario de encadenamiento hacia delante, el bucle de ejecución puede ejecutarse 65.536 veces antes de que se ejecute una excepción.
El bucle también puede producirse cuando se ejecuta Assert() una función Update() o. Maximum Execution Loop Depth puede modificarse al número máximo aproximado de veces que se espera que la ejecución se bucle. En muchos escenarios, es mejor disminuir este valor para evitar que la ejecución de la directiva entre en un bucle infinito. Esto es esencialmente poner un alto al número de disparos de reglas que pueden ocurrir durante la ejecución de directivas. Por ejemplo, si desea detener el bucle en 200, establezca este valor en 200.
Una vez publicada la directiva, la Maximum Execution Loop Depth propiedad no se puede modificar. La única opción es crear una nueva versión de la directiva y modificar el valor; que se puede hacer en la ventana Propiedades de la regla de negocio Composer.
Considere el diseño de las directivas, específicamente mediante Assert y Update
| Función | Descripción |
|---|---|
| Assert | La función Assert agrega una nueva instancia de objeto a la memoria de trabajo del motor de reglas que se va a evaluar. El motor procesa cada instancia según las condiciones y acciones que se escriben en el tipo de instancia, mediante las fases de resolución y acción de conflictos de coincidencia. |
| Actualizar | La función Update vuelve a asertar un objeto existente en la memoria de trabajo del motor de reglas para que se reevalue, en función de los nuevos datos y el estado. Al actualizar un objeto existente, solo se reevaluan las condiciones que usan el hecho actualizado y se agregan acciones a la agenda si estas condiciones se evalúan como true. La función Update hace que todas las reglas que usan los hechos actualizados se vuelvan a evaluar. Como resultado, las llamadas a la función Update pueden ser costosas, especialmente si hay un gran número de reglas. Recomendación: Como paso de solución de problemas, puede quitar update para intentar resolver la CPU alta. Esto puede devolver resultados diferentes, pero si corrige el uso de la CPU, tienes una buena idea de dónde centrar los esfuerzos de solución de problemas. |
Para obtener más información sobre Assert y Update, visite el vínculo: Effect of Engine Control Functions on Business Rule Execution - Part1
Procedimientos recomendados de diseño adicionales
- Si se crean distintos objetos de directiva, asegúrese de que están eliminados.
- Si una sola solicitud puede generar varios subprocesos para su ejecución, asegúrese de realizar pruebas de carga con un gran número de solicitudes.
- El
TypedDataTableenlace se usa mejor cuando el tamaño del conjunto de datos es pequeño, normalmente <10. ElTypedDataTableenlace es un contenedor a unDataTableen ADO.Net, que representa una tabla de datos en memoria.TypedDataTablelos objetos son objetos de datos desconectados, por lo que no hay ninguna conexión de base de datos activa. - El
DataConnectionenlace se usa mejor cuando el tamaño del conjunto de datos es grande, normalmente >=10. ElDataConnectionenlace es un contenedor a unDataSeten ADO.Net, que representa un conjunto completo de datos, incluidas tablas relacionadas, restricciones y relaciones entre las tablas.DataConnectionel tiempo de ejecución de BRE cierra los objetos.