Guia de desempenho do Azure SignalR Service
Um dos principais benefícios de usar o Serviço SignalR do Azure é a facilidade de dimensionamento de aplicativos SignalR. Num cenário de grande escala, o desempenho é um fator importante.
Este artigo descreve:
- Os fatores que afetam o desempenho do aplicativo SignalR.
- O desempenho típico em diferentes cenários de casos de uso.
- O ambiente e as ferramentas que você pode usar para gerar um relatório de desempenho.
Avaliação rápida usando métricas
Você pode monitorar facilmente seu serviço no portal do Azure. Na página Métricas da sua instância do SignalR, você pode selecionar as métricas de Carga do Servidor para ver a "pressão" do seu serviço.
O gráfico mostra a pressão de computação do seu serviço SignalR. Você pode testar seu cenário e verificar essa métrica para decidir se deseja aumentar a escala. A latência dentro do serviço SignalR permanece baixa se a carga do servidor estiver abaixo de 70%.
Nota
Se você estiver usando a unidade 50 ou maior e seu cenário estiver enviando principalmente para grupos pequenos (tamanho do <grupo 20) ou conexão única, você precisará verificar o envio para grupo pequeno ou o envio para conexão para referência. Nesses cenários, há um grande custo de roteamento que não está incluído na carga do servidor.
Definições de termos
Entrada: A mensagem de entrada para o Serviço Azure SignalR.
Saída: A mensagem de saída do Serviço Azure SignalR.
Largura de banda: O tamanho total de todas as mensagens em 1 segundo.
Modo padrão: o modo de trabalho padrão quando uma instância do Serviço Azure SignalR é criada. O Serviço SignalR do Azure espera que o servidor de aplicativos estabeleça uma conexão com ele antes de aceitar qualquer conexão de cliente.
Modo sem servidor: um modo no qual o Serviço Azure SignalR aceita apenas conexões de cliente. Nenhuma conexão com o servidor é permitida.
Descrição geral
O Serviço Azure SignalR define sete camadas Standard para diferentes capacidades de desempenho. Este guia responde às seguintes perguntas:
Qual é o desempenho típico do Serviço Azure SignalR para cada camada (unidade)?
O Serviço Azure SignalR atende aos meus requisitos de taxa de transferência de mensagens (por exemplo, enviar 100.000 mensagens por segundo)?
Para o meu cenário específico, como posso selecionar a camada adequada?
Que tipo de servidor de aplicativo (tamanho de VM) é adequado para mim? Quantos deles devo implantar?
Para responder a essas perguntas, este guia primeiro fornece uma explicação de alto nível dos fatores que afetam o desempenho. Em seguida, ilustra o máximo de mensagens de entrada e saída para cada camada para casos de uso típicos: eco, transmissão, enviar para o grupo e enviar para conexão (bate-papo ponto a ponto).
Este guia não pode cobrir todos os cenários (e diferentes casos de uso, tamanhos de mensagens, padrões de envio de mensagens e assim por diante). Mas ele fornece alguns métodos para ajudá-lo:
- Avalie seu requisito aproximado para as mensagens de entrada ou saída.
- Encontre as camadas adequadas verificando a tabela de desempenho.
Visão geral do desempenho
Esta seção descreve as metodologias de avaliação de desempenho e, em seguida, lista todos os fatores que afetam o desempenho. No final, ele fornece métodos para ajudá-lo a avaliar os requisitos de desempenho.
Metodologia
A taxa de transferência e a latência são dois aspetos típicos da verificação de desempenho. Para o Serviço Azure SignalR, cada camada de SKU tem sua própria política de limitação de taxa de transferência. A política define a taxa de transferência máxima permitida (largura de banda de entrada e saída) como a taxa de transferência máxima alcançada quando 99% das mensagens têm latência inferior a 1 segundo.
Latência é o período de tempo desde a conexão que envia a mensagem até o recebimento da mensagem de resposta do Serviço Azure SignalR. Tomemos o eco como exemplo. Cada conexão de cliente adiciona um carimbo de data/hora na mensagem. O hub do servidor de aplicativos envia a mensagem original de volta para o cliente. Assim, o atraso de propagação é facilmente calculado por cada conexão de cliente. O carimbo de data/hora é anexado para cada mensagem na transmissão, enviar para o grupo e enviar para a conexão.
Para simular milhares de conexões de cliente simultâneas, várias VMs são criadas em uma rede virtual privada no Azure. Todas essas VMs se conectam à mesma instância do Serviço Azure SignalR.
No modo padrão do Serviço Azure SignalR, as VMs do servidor de aplicativo são implantadas na mesma rede virtual privada que as VMs cliente. Todas as VMs cliente e VMs do servidor de aplicativos são implantadas na mesma rede da mesma região para evitar latência entre regiões.
Fatores de desempenho
Os seguintes fatores afetam o desempenho do SignalR.
- Camada SKU (CPU/memória)
- Número de conexões
- Tamanho da mensagem
- Taxa de envio de mensagens
- Tipo de transporte (WebSocket, Server-Sent-Event ou Long-Polling)
- Cenário de caso de uso (custo de roteamento)
- Servidor de aplicativos e conexões de serviço (no modo de servidor)
Recursos do computador
Teoricamente, a capacidade do Serviço Azure SignalR é limitada pelos recursos de computação: CPU, memória e rede. Por exemplo, mais conexões com o Serviço SignalR do Azure fazem com que o serviço use mais memória. Para um tráfego de mensagens maior (por exemplo, cada mensagem tem mais de 2.048 bytes), o Serviço Azure SignalR precisa gastar mais ciclos de CPU para processar o tráfego. Enquanto isso, a largura de banda da rede do Azure também impõe um limite para o tráfego máximo.
Tipo de transporte
O tipo de transporte é outro fator que afeta o desempenho. Os três tipos são:
- WebSocket: WebSocket é um protocolo de comunicação bidirecional e full-duplex sobre uma única conexão TCP.
- Server-Sent-Event: Server-Sent-Event é um protocolo unidirecional para enviar mensagens do servidor para o cliente.
- Long-Polling: Long-Polling requer que os clientes periodicamente sondem informações do servidor por meio de uma solicitação HTTP.
Para a mesma API sob as mesmas condições, WebSocket tem o melhor desempenho, Server-Sent-Event é mais lento e Long-Polling é o mais lento. O Serviço SignalR do Azure recomenda o WebSocket por padrão.
Custo de roteamento de mensagens
O custo de roteamento de mensagens também limita o desempenho. O Serviço Azure SignalR desempenha uma função como um roteador de mensagens, que roteia a mensagem de um conjunto de clientes ou servidores para outros clientes ou servidores. Um cenário ou API diferente requer uma política de roteamento diferente.
Para eco, o cliente envia uma mensagem para si mesmo, e o destino de roteamento também é ele mesmo. Esse padrão tem o menor custo de roteamento. Mas para difusão, envio para grupo e envio para conexão, o Serviço SignalR do Azure precisa procurar as conexões de destino por meio da estrutura de dados distribuída interna. Esse processamento extra usa mais CPU, memória e largura de banda de rede. Como resultado, o desempenho é mais lento.
No modo padrão, o servidor de aplicativos também pode se tornar um gargalo para determinados cenários. O SDK do Azure SignalR tem que invocar o hub, enquanto mantém uma conexão ao vivo com cada cliente por meio de sinais de pulsação.
No modo sem servidor, o cliente envia uma mensagem por postagem HTTP, que não é tão eficiente quanto o WebSocket.
Protocolo
Outro fator é o protocolo: JSON e MessagePack. O MessagePack é menor em tamanho e entregue mais rápido do que o JSON. No entanto, o MessagePack pode não melhorar o desempenho. O desempenho do Serviço SignalR do Azure não é sensível aos protocolos porque não decodifica a carga útil da mensagem durante o encaminhamento de mensagens de clientes para servidores ou vice-versa.
Encontrar um SKU adequado
Como você pode avaliar a capacidade de entrada/saída ou encontrar qual camada é adequada para um caso de uso específico?
Suponha que o servidor de aplicativos é poderoso o suficiente e não é o gargalo de desempenho. Em seguida, verifique a largura de banda máxima de entrada e saída para cada camada.
Avaliação rápida
Para uma avaliação rápida, assuma as seguintes configurações padrão:
- O tipo de transporte é WebSocket.
- O tamanho da mensagem é de 2.048 bytes.
- Uma mensagem é enviada a cada 1 segundo.
- O Serviço Azure SignalR está no modo padrão.
Cada camada tem sua própria largura de banda máxima de entrada e largura de banda de saída. Uma experiência de usuário suave não é garantida depois que a conexão de entrada ou saída excede o limite.
O Echo fornece a largura de banda de entrada máxima porque tem o menor custo de roteamento. Broadcast define a largura de banda máxima da mensagem de saída.
Não exceda os valores realçados nas duas tabelas seguintes.
| Eco | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| Ligações | 1,000 | 2.000 | 10.000 | 50 000 | 100.000 | 200,000 | 500.000 | 1.000.000 |
| Largura de banda de entrada | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1.000 MBps | 2.000 MBps |
| Largura de banda de saída | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1.000 MBps | 2.000 MBps |
| Difusão | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| Ligações | 1,000 | 2.000 | 10.000 | 50 000 | 100.000 | 200,000 | 500.000 | 1.000.000 |
| Largura de banda de entrada | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| Largura de banda de saída | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2.000 MBps | 4.000 MBps |
A largura de banda de entrada e a largura de banda de saída são o tamanho total da mensagem por segundo. Aqui estão as fórmulas para eles:
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
inboundConnections: O número de conexões que enviam a mensagem.
outboundConnections: O número de conexões que recebem a mensagem.
messageSize: O tamanho de uma única mensagem (valor médio). Uma mensagem pequena com menos de 1.024 bytes tem um impacto no desempenho semelhante a uma mensagem de 1.024 bytes.
sendInterval: O tempo de envio de uma mensagem. Normalmente, é 1 segundo por mensagem, o que significa enviar uma mensagem a cada segundo. Um intervalo menor significa enviar mais mensagens em um período de tempo. Por exemplo, 0,5 segundo por mensagem significa enviar duas mensagens a cada segundo.
Conexões: o limite máximo confirmado para o Serviço Azure SignalR para cada camada. Se o número de conexão for aumentado ainda mais, ele sofrerá com a limitação de conexão.
Nota
Você precisa escalar para SKU Premium_P2 ter tamanho de unidade maior que 100.
Avaliação para casos de uso complexos
Tamanho de mensagem maior ou taxa de envio diferente
O caso de uso real é mais complicado. Ele pode enviar uma mensagem maior que 2.048 bytes ou a taxa de envio de mensagens não é de uma mensagem por segundo. Vamos pegar a transmissão da Unit 100 como exemplo para descobrir como avaliar seu desempenho.
A tabela a seguir mostra um caso de uso real da transmissão. Mas o tamanho da mensagem, a contagem de conexões e a taxa de envio de mensagens são diferentes do que assumimos na seção anterior. A questão é como podemos deduzir qualquer um desses itens (tamanho da mensagem, contagem de conexões ou taxa de envio de mensagens) se conhecemos apenas dois deles.
| Difusão | Tamanho da mensagem | Mensagens de entrada simultâneas | Ligações | Intervalos de envio |
|---|---|---|---|---|
| 5 | 20 KB | 5 | 100.000 | 5 segundos |
| 2 | 256 KB | 5 | 8,000 | 5 segundos |
A fórmula a seguir é fácil de inferir com base na fórmula anterior:
outboundConnections = outboundBandwidth * sendInterval / messageSize
Para a Unidade 100, a largura de banda máxima de saída é de 400 MB da tabela anterior. Para um tamanho de mensagem de 20 KB, o máximo de conexões de saída deve ser de 400 MB * 5 / 20 KB = 100.000, o que corresponde ao valor real.
Casos de uso mistos
O caso de uso real normalmente mistura os quatro casos de uso básicos: eco, transmissão, enviar para grupo e enviar para conexão. A metodologia que você usa para avaliar a capacidade é:
- Divida os casos de uso mistos em quatro casos de uso básicos.
- Calcule a largura de banda máxima de mensagens de entrada e saída usando as fórmulas anteriores separadamente.
- Somar os cálculos de largura de banda para obter a largura de banda máxima total de entrada/saída.
Em seguida, pegue a camada adequada nas tabelas de largura de banda máxima de entrada/saída.
Nota
Para enviar uma mensagem para centenas ou milhares de pequenos grupos, ou para milhares de clientes que enviam uma mensagem uns para os outros, o custo de roteamento se tornará dominante. Tenha em conta este impacto.
Para o caso de uso de enviar uma mensagem aos clientes, certifique-se de que o servidor do aplicativo não seja o gargalo. A seção "Estudo de caso" a seguir fornece diretrizes sobre quantos servidores de aplicativos você precisa e quantas conexões de servidor você deve configurar.
Caso prático
As seções a seguir passam por quatro casos de uso típicos para transporte WebSocket: echo, broadcast, send to group e send to connection. Para cada cenário, a seção lista a capacidade atual de entrada e saída do Serviço Azure SignalR. Também explica os principais fatores que afetam o desempenho.
No modo padrão, o servidor de aplicativos cria cinco conexões de servidor com o Serviço Azure SignalR. O servidor de aplicativos usa o SDK do Serviço Azure SignalR por padrão. Nos seguintes resultados de teste de desempenho, as conexões de servidor são aumentadas para 15 (ou mais para transmissão e envio de uma mensagem para um grande grupo).
Casos de uso diferentes têm requisitos diferentes para servidores de aplicativos. A transmissão precisa de um pequeno número de servidores de aplicativos. Echo ou enviar para conexão precisa de muitos servidores de aplicativos.
Em todos os casos de uso, o tamanho padrão da mensagem é de 2.048 bytes e o intervalo de envio da mensagem é de 1 segundo.
Modo predefinido
Clientes, servidores de aplicativos Web e o Serviço Azure SignalR estão envolvidos no modo padrão. Cada cliente representa uma única conexão.
Eco
Primeiro, um aplicativo Web se conecta ao Serviço SignalR do Azure. Em segundo lugar, muitos clientes se conectam ao aplicativo Web, que redireciona os clientes para o Serviço SignalR do Azure com o token de acesso e o ponto de extremidade. Em seguida, os clientes estabelecem conexões WebSocket com o Serviço Azure SignalR.
Depois que todos os clientes estabelecem conexões, eles começam a enviar uma mensagem que contém um carimbo de data/hora para o hub específico a cada segundo. O hub ecoa a mensagem de volta ao seu cliente original. Cada cliente calcula a latência quando recebe a mensagem de eco de volta.
No diagrama a seguir, 5 a 8 (tráfego destacado em vermelho) estão em um loop. O loop é executado por uma duração padrão (5 minutos) e obtém a estatística de toda a latência da mensagem.
O comportamento do echo determina que a largura de banda máxima de entrada é igual à largura de banda máxima de saída. Para obter detalhes, consulte a tabela a seguir.
| Eco | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| Ligações | 1,000 | 2.000 | 10.000 | 50 000 | 100.000 | 200,000 | 500.000 | 1.000.000 |
| Mensagens de entrada/saída por segundo | 1,000 | 2.000 | 10.000 | 50 000 | 100.000 | 200,000 | 500.000 | 1.000.000 |
| Largura de banda de entrada/saída | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1.000 MBps | 2.000 MBps |
Nesse caso de uso, cada cliente invoca o hub definido no servidor do aplicativo. O hub apenas chama o método definido no lado do cliente original. Este hub é o hub mais leve para eco.
public void Echo(IDictionary<string, object> data)
{
Clients.Client(Context.ConnectionId).SendAsync("RecordLatency", data);
}
Mesmo para esse hub simples, a pressão de tráfego no servidor de aplicativos é proeminente à medida que a carga de mensagens de entrada de eco aumenta. Essa pressão de tráfego requer muitos servidores de aplicativos para grandes camadas de SKU. A tabela a seguir lista a contagem do servidor de aplicativos para cada camada.
| Eco | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| Ligações | 1,000 | 2.000 | 10.000 | 50 000 | 100.000 | 200,000 | 500.000 | 1.000.000 |
| Contagem do servidor de aplicativos | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Nota
O número de conexão do cliente, o tamanho da mensagem, a taxa de envio de mensagens, a camada de SKU e a CPU/memória do servidor de aplicativos afetam o desempenho geral do eco.
Difusão
Para transmissão, quando o aplicativo Web recebe a mensagem, ele transmite para todos os clientes. Quanto mais clientes houver para transmitir, mais tráfego de mensagens haverá para todos os clientes. Veja o seguinte diagrama.
Um pequeno número de clientes está transmitindo. A largura de banda da mensagem de entrada é pequena, mas a largura de banda de saída é enorme. A largura de banda da mensagem de saída aumenta à medida que a conexão do cliente ou a taxa de transmissão aumenta.
A tabela a seguir resume o máximo de conexões de cliente, contagem de mensagens de entrada/saída e largura de banda.
| Difusão | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| Ligações | 1,000 | 2.000 | 10.000 | 50 000 | 100.000 | 200,000 | 500.000 | 1.000.000 |
| Mensagens de entrada por segundo | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Mensagens de saída por segundo | 2.000 | 4,000 | 20.000 | 100.000 | 200,000 | 400,000 | 1.000.000 | 2,000,000 |
| Largura de banda de entrada | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| Largura de banda de saída | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2.000 MBps | 4.000 MBps |
Os clientes de radiodifusão que postam mensagens não são mais do que quatro. Eles precisam de menos servidores de aplicativos em comparação com o eco porque a quantidade de mensagens de entrada é pequena. Dois servidores de aplicativos são suficientes para considerações de SLA e desempenho. Mas você deve aumentar as conexões de servidor padrão para evitar desequilíbrio, especialmente para unidades maiores que 50.
| Difusão | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| Ligações | 1,000 | 2.000 | 10.000 | 50 000 | 100.000 | 200,000 | 500.000 | 1.000.000 |
| Contagem do servidor de aplicativos | 1 | 1 | 5 | 2 | 2 | 4 | 10 | 20 |
Nota
Aumente as conexões de servidor padrão de 5 para 40 em cada servidor de aplicativo para evitar possíveis conexões de servidor desequilibradas com o Serviço Azure SignalR.
O número de conexão do cliente, o tamanho da mensagem, a taxa de envio de mensagens e a camada de SKU afetam o desempenho geral da transmissão.
Enviar para o grupo
O caso de uso enviar para o grupo tem um padrão de tráfego semelhante à transmissão. A diferença é que, depois que os clientes estabelecem conexões WebSocket com o Serviço SignalR do Azure, eles devem ingressar em grupos antes de poderem enviar uma mensagem para um grupo específico. O diagrama a seguir ilustra o fluxo de tráfego.
A contagem de membros e grupos do grupo são dois fatores que afetam o desempenho. Para simplificar a análise, definimos dois tipos de grupos:
Grupo pequeno: Cada grupo tem 10 conexões. O número do grupo é igual a (contagem máxima de conexão) / 10. Por exemplo, para a Unidade 1, se houver 1.000 contagens de conexão, então temos 1000 / 10 = 100 grupos.
Grupo grande: O número do grupo é sempre 10. A contagem de membros do grupo é igual a (contagem máxima de conexão) / 10. Por exemplo, para a Unidade 1, se houver 1.000 contagens de conexão, cada grupo terá 1000 / 10 = 100 membros.
Enviar para o grupo traz um custo de roteamento para o Serviço SignalR do Azure porque ele precisa encontrar as conexões de destino por meio de uma estrutura de dados distribuída. À medida que as conexões de envio aumentam, o custo aumenta.
Grupo pequeno
O custo de roteamento é significativo para enviar mensagens para muitos grupos pequenos. Atualmente, a implementação do Serviço Azure SignalR atinge o limite de custo de roteamento na Unidade 50. Adicionar mais CPU e memória não ajuda, então a Unidade 100 não pode melhorar ainda mais por design. Se precisar de mais largura de banda de entrada, entre em contato com o suporte ao cliente.
| Enviar para um pequeno grupo | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| Ligações | 1,000 | 2.000 | 10.000 | 50 000 | 100.000 | 200,000 | 500.000 | 1.000.000 |
| Contagem de membros do grupo | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Contagem de grupos | 100 | 200 | 1,000 | 5.000 | 10.000 | 20.000 | 50 000 | 100.000 |
| Mensagens de entrada por segundo | 200 | 400 | 2.000 | 10.000 | 10.000 | 20.000 | 50 000 | 100.000 |
| Largura de banda de entrada | 400 KBps | 800 KBps | 4 MBps | 20 MBps | 20 MBps | 40 MBps | 100 MBps | 200 MBps |
| Mensagens de saída por segundo | 2.000 | 4,000 | 20.000 | 100.000 | 100.000 | 200,000 | 500.000 | 1.000.000 |
| Largura de banda de saída | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 200 MBps | 400 MBps | 1.000 MBps | 2.000 MBps |
Muitas conexões de cliente estão chamando o hub, portanto, o número do servidor do aplicativo também é crítico para o desempenho. A tabela a seguir lista as contagens sugeridas do servidor de aplicativos.
| Enviar para um pequeno grupo | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| Ligações | 1,000 | 2.000 | 10.000 | 50 000 | 100.000 | 200,000 | 500.000 | 1.000.000 |
| Contagem do servidor de aplicativos | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Nota
O número de conexão do cliente, o tamanho da mensagem, a taxa de envio de mensagens, o custo de roteamento, a camada de SKU e a CPU/memória do servidor de aplicativos afetam o desempenho geral do envio para pequenos grupos.
A contagem de grupos, a contagem de membros do grupo listados na tabela não são limites rígidos. Esses valores de parâmetro são selecionados para estabelecer um cenário de referência estável. Por exemplo, não há problema em atribuir cada conneciton a um grupo distinto. Sob essa configuração, o desempenho está próximo de enviar para a conexão.
Grande grupo
Para enviar para grupo grande, a largura de banda de saída torna-se o gargalo antes de atingir o limite de custo de roteamento. A tabela a seguir lista a largura de banda máxima de saída, que é quase a mesma da transmissão.
| Enviar para grupo grande | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| Ligações | 1,000 | 2.000 | 10.000 | 50 000 | 100.000 | 200,000 | 500.000 | 1.000.000 |
| Contagem de membros do grupo | 100 | 200 | 500 | 1,000 | 2.000 | 5.000 | 10.000 | 20.000 |
| Contagem de grupos | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Mensagens de entrada por segundo | 20 | 20 | 20 | 20 | 20 | 20 | 20 | 20 |
| Largura de banda de entrada | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps |
| Mensagens de saída por segundo | 2.000 | 4,000 | 20.000 | 100.000 | 200,000 | 400,000 | 1.000.000 | 2,000,000 |
| Largura de banda de saída | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2.000 MBps | 4.000 MBps |
A contagem de conexões de envio não é superior a 40. A carga no servidor de aplicativos é pequena, portanto, o número sugerido de aplicativos Web é pequeno.
| Enviar para grupo grande | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| Ligações | 1,000 | 2.000 | 10.000 | 50 000 | 100.000 | 200,000 | 500.000 | 1.000.000 |
| Contagem do servidor de aplicativos | 1 | 5 | 2 | 2 | 2 | 4 | 10 | 20 |
Nota
Aumente as conexões de servidor padrão de 5 para 40 em cada servidor de aplicativo para evitar possíveis conexões de servidor desequilibradas com o Serviço Azure SignalR.
O número de conexão do cliente, o tamanho da mensagem, a taxa de envio de mensagens, o custo de roteamento e a camada de SKU afetam o desempenho geral do envio para um grupo grande.
Enviar para conexão
No caso de uso de enviar para conexão, quando os clientes estabelecem as conexões com o Serviço SignalR do Azure, cada cliente chama um hub especial para obter sua própria ID de conexão . O benchmark de desempenho coleta todos os IDs de conexão, embaralha-os e os reatribui a todos os clientes como um destino de envio. Os clientes continuam enviando a mensagem para a conexão de destino até que o teste de desempenho termine.
O custo de roteamento para enviar para conexão é semelhante ao custo para enviar para grupo pequeno.
À medida que o número de conexões aumenta, o custo de roteamento se torna um fator crítico que limita o desempenho geral. Notavelmente, a Unidade 20 marca o limite em que o serviço atinge o gargalo de roteamento. Aumentos adicionais na contagem de unidades não produzem melhorias de desempenho, a menos que haja uma mudança para Premium_P2(unidade >= 100), o que melhora os recursos de roteamento.
A tabela a seguir é um resumo estatístico após muitas rodadas de execução do benchmark de conexão enviar para.
| Enviar para conexão | Unidade 1 | Unidade 2 | Unidade 20 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| Ligações | 1,000 | 2.000 | 20.000 | 50 000 | 100.000 | 200,000 | 500.000 | 1.000.000 |
| Mensagens de entrada/saída por segundo | 1,000 | 2.000 | 20.000 | 20.000 | 20.000 | 40.000 | 100.000 | 200,000 |
| Largura de banda de entrada/saída | 2 MBps | 4 MBps | 40 MBps | 40 MBps | 40 MBps | 80 MBps | 200 MBps | 400 MBps |
Nota
Apesar da estagnação das mensagens de entrada/saída por segundo após a Unidade 20, a capacidade para mais conexões continua a crescer. Em cenários de negócios reais, muitas vezes é a contagem de conexões, e não sua atividade simultânea de envio de mensagens, que forma o gargalo. É incomum que todas as conexões enviem mensagens ativamente em frequências tão altas quanto o teste de benchmark.
Este caso de uso requer alta carga no lado do servidor de aplicativos. Consulte a contagem sugerida do servidor de aplicativos na tabela a seguir.
| Enviar para conexão | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| Ligações | 1,000 | 2.000 | 10.000 | 50 000 | 100.000 | 200,000 | 500.000 | 1.000.000 |
| Contagem do servidor de aplicativos | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Nota
O número de conexão do cliente, o tamanho da mensagem, a taxa de envio de mensagens, o custo de roteamento, a camada de SKU e a CPU/memória do servidor de aplicativos afetam o desempenho geral da conexão de envio para.
ASP.NET SignalR
O Serviço Azure SignalR fornece a mesma capacidade de desempenho para ASP.NET SignalR.
Modo sem servidor
Os clientes e o Serviço Azure SignalR estão envolvidos no modo sem servidor. Cada cliente representa uma única conexão. O cliente envia mensagens através da API REST para outro cliente ou transmite mensagens para todos.
Enviar mensagens de alta densidade através da API REST não é tão eficiente quanto usar WebSocket. Ele requer que você crie uma nova conexão HTTP toda vez, e isso é um custo extra no modo sem servidor.
Transmissão através da API REST
Todos os clientes estabelecem conexões WebSocket com o Serviço Azure SignalR. Em seguida, alguns clientes começam a transmitir através da API REST. O envio de mensagens (entrada) é todo através de HTTP Post, o que não é eficiente em comparação com o WebSocket.
| Transmissão através da API REST | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| Ligações | 1,000 | 2.000 | 10.000 | 50 000 | 100.000 | 200,000 | 500.000 | 1.000.000 |
| Mensagens de entrada por segundo | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Mensagens de saída por segundo | 2.000 | 4,000 | 20.000 | 100.000 | 200,000 | 400,000 | 1.000.000 | 2,000,000 |
| Largura de banda de entrada | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps | 4 KBps |
| Largura de banda de saída | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2.000 MBps | 4.000 MBps |
Enviar para o usuário através da API REST
O benchmark atribui nomes de usuário a todos os clientes antes que eles comecem a se conectar ao Serviço Azure SignalR. Depois que os clientes estabelecem conexões WebSocket com o Serviço Azure SignalR, eles começam a enviar mensagens para outras pessoas por meio de HTTP Post.
| Enviar para o usuário através da API REST | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| Ligações | 1,000 | 2.000 | 10.000 | 50 000 | 100.000 | 200,000 | 500.000 | 1.000.000 |
| Mensagens de entrada/saída por segundo | 200 | 400 | 2.000 | 10.000 | 20.000 | 40.000 | 100.000 | 200,000 |
| Largura de banda de entrada/saída | 400 KBps | 800 KBps | 4 MBps | 20 MBps | 40 MBps | 80 MBps | 200 MBps | 400 MBps |
Ambientes de teste de desempenho
Para todos os casos de uso listados acima, conduzimos os testes de desempenho em um ambiente do Azure. No máximo, usamos 200 VMs cliente e 100 VMs de servidor de aplicativo. Aqui estão alguns detalhes:
Tamanho da VM cliente: StandardDS2V2 (2 vCPU, memória 7G)
Tamanho da VM do servidor de aplicativos: StandardF4sV2 (4 vCPU, memória 8G)
Conexões de servidor do SDK do Azure SignalR: 15
Ferramentas de desempenho
Você pode encontrar ferramentas de desempenho para o Serviço Azure SignalR no GitHub.
Próximos passos
Neste artigo, você obteve uma visão geral do desempenho do Serviço SignalR do Azure em cenários típicos de casos de uso.
Para obter detalhes sobre os componentes internos do serviço e o dimensionamento para ele, leia os seguintes guias: