Desempenho do SignalR (SignalR 1.x)

por Patrick Fletcher

Aviso

Esta documentação não é para a versão mais recente do SignalR. Dê uma olhada em ASP.NET Core SignalR.

Este tópico descreve como projetar, medir e melhorar o desempenho em um aplicativo SignalR.

Para obter uma apresentação recente sobre o desempenho e o dimensionamento do SignalR, consulte Dimensionando a Web em tempo real com ASP.NET SignalR.

Este tópico contém as seguintes seções:

• Considerações sobre o design
• Ajustando seu servidor SignalR para desempenho
• Solucionando problemas de desempenho
• Usando contadores de desempenho do SignalR
• Usando outros contadores de desempenho
• Outros recursos

Considerações sobre o design

Esta seção descreve padrões que podem ser implementados durante o design de um aplicativo SignalR, para garantir que o desempenho não esteja sendo prejudicado gerando tráfego de rede desnecessário.

Frequência da mensagem de limitação

Mesmo em um aplicativo que envia mensagens em alta frequência (como um aplicativo de jogos em tempo real), a maioria dos aplicativos não precisa enviar mais do que algumas mensagens por segundo. Para reduzir a quantidade de tráfego gerada por cada cliente, um loop de mensagem pode ser implementado que filas e envia mensagens com não mais frequência do que uma taxa fixa (ou seja, até um determinado número de mensagens serão enviadas a cada segundo, se houver mensagens nesse intervalo de tempo a serem enviadas). Para obter um aplicativo de exemplo que limita as mensagens a uma determinada taxa (do cliente e do servidor), consulte High-Frequency Realtime with SignalR.

Reduzindo o tamanho da mensagem

Você pode reduzir o tamanho de uma mensagem SignalR reduzindo o tamanho dos objetos serializados. No código do servidor, se você estiver enviando um objeto que contém propriedades que não precisam ser transmitidas, impeça que essas propriedades sejam serializadas usando o JsonIgnore atributo . Os nomes das propriedades também são armazenados na mensagem; os nomes das propriedades podem ser reduzidos usando o JsonProperty atributo . O exemplo de código a seguir demonstra como excluir uma propriedade de ser enviada ao cliente e como reduzir nomes de propriedade:

Código do servidor .NET que demonstra o atributo JsonIgnore para excluir dados de serem enviados ao cliente e o atributo JsonProperty para reduzir o tamanho da mensagem

using Newtonsoft.Json; 
using System; 
public class ShapeModel
{
[JsonProperty("l")]
    public double Left { get; set; }
[JsonProperty("t")]
    public double Top { get; set; }
    // We don't want the client to get the "LastUpdatedBy" property
[JsonIgnore]
    public string LastUpdatedBy { get; set; }
}

Para manter a legibilidade/manutenção no código do cliente, os nomes de propriedade abreviados podem ser remapeados para nomes amigáveis para humanos após o recebimento da mensagem. O exemplo de código a seguir demonstra uma possível maneira de remapear nomes reduzidos para os mais longos, definindo um contrato de mensagem (mapeamento) e usando a reMap função para aplicar o contrato à classe de mensagem otimizada:

Código JavaScript do lado do cliente que remapea nomes de propriedade abreviados para nomes legíveis por humanos

function reMap(smallObject, contract) {
    var largeObject = {};
    for (var smallProperty in contract) {
        largeObject[contract[smallProperty]] = smallObject[smallProperty];
    }
    return largeObject;
}
var shapeModelContract = {
    l: "left",
    t: "top"
};
myHub.client.setShape = function (shapeModelSmall) {
    var shapeModel = reMap(shapeModelSmall, shapeModelContract);
    // shapeModelSmall has "l" and "t" properties  but after remapping
    // shapeModel now has "left" and "top" properties
};

Os nomes também podem ser reduzidos em mensagens do cliente para o servidor, usando o mesmo método.

Reduzir o volume de memória (ou seja, a quantidade de memória usada para a mensagem) do objeto de mensagem também pode melhorar o desempenho. Por exemplo, se o intervalo completo de um int não for necessário, um short ou byte poderá ser usado.

Como as mensagens são armazenadas no barramento de mensagens na memória do servidor, reduzir o tamanho das mensagens também pode resolver problemas de memória do servidor.

Ajustando seu servidor SignalR para desempenho

As configurações a seguir podem ser usadas para ajustar seu servidor para melhorar o desempenho em um aplicativo SignalR. Para obter informações gerais sobre como melhorar o desempenho em um aplicativo ASP.NET, consulte Aprimorando ASP.NET desempenho.

Configurações do SignalR

• DefaultMessageBufferSize: por padrão, o SignalR retém 1000 mensagens na memória por hub por conexão. Se mensagens grandes estiverem sendo usadas, isso poderá criar problemas de memória que podem ser atenuados reduzindo esse valor. Essa configuração pode ser definida no Application_Start manipulador de eventos em um aplicativo ASP.NET ou no Configuration método de uma classe de inicialização OWIN em um aplicativo auto-hospedado. O exemplo a seguir demonstra como reduzir esse valor para reduzir o volume de memória do aplicativo, a fim de reduzir a quantidade de memória do servidor usada:

  Código do servidor .NET no Global.asax para diminuir o tamanho do buffer de mensagem padrão

  protected void Application_Start(object sender, EventArgs e)
  {
      GlobalHost.Configuration.DefaultMessageBufferSize = 500;
  }
  

Configurações do IIS

• Máximo de solicitações simultâneas por aplicativo: aumentar o número de solicitações simultâneas do IIS aumentará os recursos do servidor disponíveis para atender às solicitações. O valor padrão é 5000; para aumentar essa configuração, execute os seguintes comandos em um prompt de comando com privilégios elevados:

  cd %windir%\System32\inetsrv\
  appcmd.exe set config /section:system.webserver/serverRuntime 
          /appConcurrentRequestLimit:10000
  

ASP.NET configuração

Esta seção inclui as configurações que podem ser definidas no aspnet.config arquivo. Esse arquivo é encontrado em um dos dois locais, dependendo da plataforma:

• %windir%\Microsoft.NET\Framework\v4.0.30319\aspnet.config
• %windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet.config

ASP.NET configurações que podem melhorar o desempenho do SignalR incluem o seguinte:

• Máximo de solicitações simultâneas por CPU: aumentar essa configuração pode aliviar gargalos de desempenho. Para aumentar essa configuração, adicione a seguinte configuração ao aspnet.config arquivo:

  <?xml version="1.0" encoding="UTF-8" ?>
  <configuration>
      <system.web>
          <applicationPool maxConcurrentRequestsPerCPU="20000" />
      </system.web>
  </configuration>
  

• Limite de Fila de Solicitação: quando o número total de conexões exceder a maxConcurrentRequestsPerCPU configuração, ASP.NET iniciará a limitação de solicitações usando uma fila. Para aumentar o tamanho da fila, você pode aumentar a requestQueueLimit configuração. Para fazer isso, adicione a seguinte configuração ao processModel nó no (em config/machine.config vez de aspnet.config):

  <processModel autoConfig="false" requestQueueLimit="250000" />
  

Solucionando problemas de desempenho

Esta seção descreve maneiras de encontrar gargalos de desempenho em seu aplicativo.

Verificando se o WebSocket está sendo usado

Embora o SignalR possa usar uma variedade de transportes para comunicação entre o cliente e o servidor, o WebSocket oferece uma vantagem significativa de desempenho e deve ser usado se o cliente e o servidor dão suporte a ele. Para determinar se o cliente e o servidor atendem aos requisitos do WebSocket, consulte Transportes e fallbacks. Para determinar qual transporte está sendo usado em seu aplicativo, você pode usar as ferramentas de desenvolvedor do navegador e examinar os logs para ver qual transporte está sendo usado para a conexão. Para obter informações sobre como usar as ferramentas de desenvolvimento do navegador na Internet Explorer e no Chrome, consulte Transportes e Fallbacks.

Usando contadores de desempenho do SignalR

Esta seção descreve como habilitar e usar contadores de desempenho do SignalR, encontrados no Microsoft.AspNet.SignalR.Utils pacote.

Instalando signalr.exe

Contadores de desempenho podem ser adicionados ao servidor usando um utilitário chamado SignalR.exe. Para instalar esse utilitário, siga estas etapas:

1. No Visual Studio, selecione FerramentasGerenciador de Pacotes>> NuGetGerenciar Pacotes NuGet para solução

2. Pesquise signalr.utils e selecione Instalar.

   

3. Aceite o contrato de licença para instalar o pacote.

4. SignalR.exe será instalado em <project folder>/packages/Microsoft.AspNet.SignalR.Utils.<version>/tools.

Instalando contadores de desempenho com SignalR.exe

Para instalar contadores de desempenho do SignalR, execute SignalR.exe em um prompt de comando com privilégios elevados com o seguinte parâmetro:

SignalR.exe ipc

Para remover contadores de desempenho do SignalR, execute SignalR.exe em um prompt de comando com privilégios elevados com o seguinte parâmetro:

SignalR.exe upc

Contadores de desempenho do SignalR

O pacote de utilitários instala os seguintes contadores de desempenho. Os contadores "Total" medem o número de eventos desde o último pool de aplicativos ou reinicialização do servidor.

Métricas de conexão

As métricas a seguir medem os eventos de tempo de vida da conexão que ocorrem. Para obter mais informações, consulte Noções básicas e tratamento de eventos de tempo de vida da conexão.

• Conexões conectadas
• Conexões Reconectadas
• Conexões desconectadas
• Conexões Atuais

Métricas de mensagens

As métricas a seguir medem o tráfego de mensagens gerado pelo SignalR.

• Total de Mensagens de Conexão Recebidas
• Total de Mensagens de Conexão Enviadas
• Mensagens de conexão recebidas/s
• Mensagens de conexão enviadas/s

Métricas do barramento de mensagens

As métricas a seguir medem o tráfego por meio do barramento de mensagens do SignalR interno, a fila na qual todas as mensagens do SignalR de entrada e saída são colocadas. Uma mensagem é Publicada quando é enviada ou transmitida. Um Assinante neste contexto é uma assinatura no barramento de mensagens; isso deve ser igual ao número de clientes mais o próprio servidor. Um Trabalho Alocado é um componente que envia dados para conexões ativas; um Trabalhador Ocupado é aquele que está enviando ativamente uma mensagem.

• Total de mensagens recebidas do barramento de mensagens
• Mensagens recebidas/s do barramento de mensagens
• Total de Mensagens do Barramento de Mensagens Publicadas
• Mensagens do Barramento de Mensagens Publicadas/S
• Assinantes do Barramento de Mensagens Atuais
• Total de Assinantes do Barramento de Mensagens
• Assinantes do Barramento de Mensagens/S
• Trabalhos Alocados do Barramento de Mensagens
• Trabalhadores ocupados do Barramento de Mensagens
• Tópicos atuais do Barramento de Mensagens

Métricas de erro

As métricas a seguir medem erros gerados pelo tráfego de mensagens do SignalR. Erros de resolução de hub ocorrem quando um hub ou método de hub não pode ser resolvido. Erros de invocação de hub são exceções geradas ao invocar um método de hub. Erros de transporte são erros de conexão gerados durante uma solicitação OU resposta HTTP.

• Erros: Todo o Total
• Erros: Tudo/S
• Erros: Total de Resolução do Hub
• Erros: Resolução do Hub/s
• Erros: Total de Invocação do Hub
• Erros: Invocação do Hub/S
• Erros: Total de Transporte
• Erros: Transporte/s

Métricas de expansão

As métricas a seguir medem o tráfego e os erros gerados pelo provedor de expansão. Um Stream nesse contexto é uma unidade de escala usada pelo provedor de expansão; esta será uma tabela se SQL Server for usado, um Tópico se o Barramento de Serviço for usado e uma Assinatura se o Redis for usado. Por padrão, apenas um fluxo é usado, mas isso pode ser aumentado por meio da configuração no SQL Server e no Barramento de Serviço. Um fluxo de buffer é aquele que inseriu um estado com falha; quando o fluxo estiver no estado com falha, todas as mensagens enviadas para o backplane falharão imediatamente até que o fluxo não esteja mais falhando. O Comprimento da Fila de Envio é o número de mensagens que foram postadas, mas ainda não enviadas.

• Mensagens do barramento de mensagens de expansão recebidas/s
• Total de fluxos de expansão
• Fluxos do Scaleout Abertos
• Buffer de fluxos de expansão
• Total de erros de scaleout
• Erros de scaleout/s
• Tamanho da Fila de Envio do Scaleout

Para obter mais informações sobre o que esses contadores estão medindo, consulte Scaleout do SignalR com Barramento de Serviço do Azure.

Usando outros contadores de desempenho

Os contadores de desempenho a seguir também podem ser úteis para monitorar o desempenho do aplicativo.

Memória

• Bytes de memória CLR do .NET em todos os Heaps (para w3wp)

ASP.NET

• ASP.NET\Solicitações Atuais
• ASP.NET\Enfileirado
• ASP.NET\Rejeitado

CPU

• Informações do Processador\Tempo do Processador

TCP/IP

• TCPv6/Connections Established
• TCPv4/Conexões Estabelecidas

Serviço Web

• Serviço Web\Conexões Atuais
• Serviço Web\Conexões Máximas

Threading

• Bloqueios CLR do .NETAndThreads# dos Threads lógicos atuais
• .NET CLR LocksAnd Threads# de Threads físicos atuais

Outros recursos

Para obter mais informações sobre ASP.NET monitoramento e ajuste de desempenho, consulte os seguintes tópicos:

• Visão geral do desempenho do ASP.NET
• ASP.NET uso de thread no IIS 7.5, IIS 7.0 e IIS 6.0
• Elemento <applicationPool> (configurações da Web)