Compartilhar via


Desempenho (Service Broker)

Aplica-se a:SQL ServerInstância Gerenciada de SQL do Azure

O desempenho de um aplicativo Service Broker é geralmente determinado por dois fatores:

  • O número de mensagens que chegam dentro de um período de tempo especificado
  • A velocidade com que o aplicativo processa cada mensagem

Monitorar esses dois fatores é a chave para entender o desempenho do aplicativo.

O Service Broker fornece um conjunto de contadores de desempenho que oferecem informações sobre suas atividades. O Service Broker também registra erros graves no log de erros do SQL Server e no log de eventos do Aplicativo windows. Para obter mais informações, confira os seguintes artigos:

Ajustar um procedimento armazenado do Service Broker

Normalmente, ajustar um procedimento armazenado que usa o Service Broker não é diferente de ajustar qualquer outro procedimento armazenado. No entanto, há outras considerações.

Primeiro, use a WAITFOR cláusula. As mensagens raramente chegam em intervalos previsíveis. Mesmo em um serviço em que as mensagens chegam aproximadamente à mesma taxa que o procedimento armazenado processa as mensagens, pode haver momentos em que nenhuma mensagem está disponível. Portanto, o procedimento deve usar uma WAITFOR cláusula com uma RECEIVE instrução ou com uma GET CONVERSATION GROUP instrução. Sem WAITFOR, essas instruções retornam imediatamente quando não há mensagens disponíveis na fila. Dependendo da implementação do procedimento armazenado, o procedimento poderá repetir a execução da instrução, consumindo recursos desnecessariamente, ou poderá interromper apenas para ser reativado logo em seguida, consumindo mais recursos do que simplesmente continuar em execução.

Você permite a imprevisibilidade no cronograma usando a cláusula WAITFOR com a instrução RECEIVE ou GET CONVERSATION GROUP. Se o aplicativo for executado continuamente como um serviço em segundo plano, você não especifica um tempo limite na WAITFOR instrução. Se o aplicativo for ativado pelo Service Broker ou for executado como um trabalho agendado, especifique um tempo limite curto; por exemplo, 500 milissegundos. Um aplicativo que usa a instrução WAITFOR manipula normalmente intervalos imprevisíveis entre mensagens. Da mesma forma, um aplicativo ativado que sai após um curto tempo limite não consome recursos quando não há mensagens a serem processadas.

O Service Broker garante que apenas uma instância de um aplicativo por vez possa receber mensagens para conversas que compartilham um identificador de grupo de conversa. Projete seus aplicativos para tirar proveito do bloqueio do grupo de conversa para sincronização. Se seu aplicativo mantiver estados, considere usar o identificador do grupo de conversa para identificar o estado da conversa. Processe várias mensagens para um grupo de conversa na mesma transação. Em geral, porém, processe apenas mensagens para um único grupo de conversa em uma determinada transação. Isso ajuda a assegurar que mais de uma instância do aplicativo possa processar mensagens, mesmo quando o número de grupos de conversa for relativamente pequeno.

Além disso, evite usar a retenção de mensagens. Manter uma tabela de logs separada que salva as informações mais importantes de uma mensagem melhora o desempenho. Use a retenção de mensagens somente quando o aplicativo exigir as mensagens exatas enviadas e recebidas.

A seguir, encerre as conversas quando a tarefa for concluída. O Service Broker mantém o estado de cada conversa ativa. Embora a quantidade de estado para uma conversa específica seja pequena, um aplicativo que não encerra conversas pode sofrer um desempenho reduzido ao longo do tempo.

Finalmente, mantenha as transações curtas. Por exemplo, se o padrão de conversa para o serviço envolver um grande número de mensagens no mesmo grupo de conversa, limitar o número de mensagens processadas em cada transação poderá melhorar a taxa de transferência geral.