Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Se aplica a:
SQL ServerAzure SQL Managed Instance
El rendimiento de una aplicación de Service Broker suele estar determinado por dos factores:
- Número de mensajes que llegan dentro de un período de tiempo especificado
- Velocidad a 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. Vea los siguientes artículos para más información:
- Vistas de administración dinámica relacionadas con Service Broker (Transact-SQL)
- Estadísticas de Broker (objeto de SQL Server)
- Categoría de eventos del broker
Optimizar un procedimiento almacenado de Service Broker
Normalmente, la optimización de un procedimiento almacenado que usa Service Broker no es diferente de la optimización de ningún otro procedimiento almacenado. Sin embargo, hay otras consideraciones.
En primer lugar, utilice la WAITFOR cláusula. Los mensajes no suelen llegar en intervalos predecibles. Incluso en un servicio en el que los mensajes llegan aproximadamente a la misma velocidad que el procedimiento almacenado procesa los mensajes, puede haber ocasiones en las que no haya mensajes disponibles. Por lo tanto, el procedimiento debe usar una WAITFOR cláusula con una RECEIVE declaración o con una GET CONVERSATION GROUP declaración. Sin WAITFOR, estas instrucciones regresan inmediatamente si no hay mensajes disponibles en la cola. Dependiendo de la implementación del procedimiento almacenado, el procedimiento podría volver a ejecutar la instrucción, consumiendo recursos innecesariamente, o podría salir solo para reactivarse poco después, utilizando más recursos que si simplemente continuara ejecutándose.
Se permite la imprevisibilidad en el tiempo mediante la cláusula WAITFOR con la instrucción RECEIVE o GET CONVERSATION GROUP. Si la aplicación se ejecuta continuamente como un servicio en segundo plano, no se especifica un tiempo de espera en la WAITFOR instrucción . Si Service Broker activa la aplicación o se ejecuta como un trabajo programado, especifique un breve tiempo de espera; por ejemplo, 500 milisegundos. Una aplicación que usa la WAITFOR instrucción controla correctamente intervalos imprevisibles entre los mensajes. Del mismo modo, una aplicación activada que se cierra después de un breve tiempo de espera no consume recursos cuando no hay ningún mensaje que procesar.
Service Broker garantiza que solamente 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 solamente 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. Use la retención de mensajes solo cuando la aplicación requiera los mensajes exactos enviados y recibidos.
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 termina las conversaciones podría sufrir una reducción del rendimiento a lo largo del tiempo.
Por último, mantenga las transacciones cortas. Por ejemplo, si el patrón de conversación para el servicio implica un gran número de mensajes en el mismo grupo de conversación, limitar el número de mensajes procesados en cada transacción podría mejorar el rendimiento general.