Rendimiento (Service Broker)
El rendimiento de una aplicación de Service Broker suele estar determinado por dos factores:
El número de mensajes que llega en un período de tiempo especificado.
La velocidad con la que la aplicación procesa cada mensaje.
La clave para conocer el rendimiento de la aplicación se basa en la supervisión estos dos factores.
Service Broker proporciona un conjunto de contadores de rendimiento que proporcionan información sobre sus actividades. Service Broker también registra errores graves en el registro de errores de SQL Server y en el registro de eventos de aplicación de Windows. Para obtener más información sobre los contadores de rendimiento, las vistas de administración dinámica y los eventos de traza para Service Broker, vea Supervisar (Service Broker).
Optimizar un procedimiento almacenado de Service Broker
En su mayor parte, la optimización de un procedimiento almacenado que utiliza Service Broker no es distinta de la optimización de cualquier otro procedimiento almacenado. Sin embargo, existen algunas consideraciones adicionales.
En primer lugar, utilice la cláusula WAITFOR. Los mensajes no suelen llegar en intervalos predecibles. Incluso en un servicio donde los mensajes llegan casi a la misma velocidad que el procedimiento almacenado procesa los mensajes, puede haber ocasiones donde ningún mensaje esté disponible. Por tanto, el procedimiento debe utilizar una cláusula WAITFOR con una instrucción RECEIVE o con una instrucción GET CONVERSATION GROUP. Sin WAITFOR, estas instrucciones vuelven inmediatamente cuando no hay mensajes disponibles en la cola. Dependiendo de la implementación del procedimiento almacenado, éste puede volver de nuevo desde la instrucción, consumiendo recursos innecesariamente, o puede abandonarse sólo para reactivarse poco después, consumiendo más recursos que si se sigue ejecutando.
Para permitir la imprecisión del tiempo utilice la cláusula WAITFOR con la instrucción RECEIVE o GET CONVERSATION GROUP. Si la aplicación se ejecuta de forma continua como un servicio en segundo plano, no especifique tiempo de espera en la instrucción WAITFOR. Si Service Broker activa la aplicación, o si ésta se ejecuta como un trabajo programado, especifique un tiempo de espera corto, por ejemplo, 500 milisegundos. Una aplicación que utiliza la instrucción WAITFOR controla los intervalos impredecibles entre mensajes sin problemas. Del mismo modo, una aplicación activada que existe tras un tiempo de espera corto no consume recursos cuando no hay mensajes que procesar.
Service Broker garantiza que sólo una instancia de una aplicación a la vez puede recibir mensajes de conversaciones que comparten un identificador de grupo de conversación. Diseñe las aplicaciones para aprovecharse del bloqueo de grupo de conversación para la sincronización. Si la aplicación mantiene el estado, plantéese utilizar el identificador de grupo de conversación para identificar el estado de la conversación. Procese varios mensajes de un grupo de conversación en la misma transacción. Sin embargo, en general, procese sólo los mensajes de un único grupo de conversación en una transacción dada. Esto permite garantizar que más de una instancia de la aplicación puede procesar mensajes, incluso cuando el número de grupos de conversación sea relativamente pequeño.
Además, evite utilizar la retención de mensajes. El mantenimiento de una tabla de registro independiente que guarda la información más importante de un mensaje mejora el rendimiento. Utilice la retención de mensajes sólo en caso de que la aplicación requiera enviar y recibir los mensajes exactos.
A continuación, finalice las conversaciones cuando la tarea finalice. Service Broker mantiene el estado para cada conversación activa. Aunque la cantidad de estado de una conversación determinada es pequeña, una aplicación que no finaliza conversaciones puede ver reducido su rendimiento con el tiempo.
Por último, mantenga las transacciones cortas. Por ejemplo, si el patrón de conversación del servicio implica un número considerable de mensajes en el mismo grupo de conversación, la limitación del número de mensajes procesados en cada transacción puede mejorar el rendimiento global.
Vea también