Guia de desempenho para Serviço do Azure SignalR
Um dos principais benefícios de usar o Serviço do Azure SignalR é a facilidade de dimensionar aplicativos do SignalR. Em um 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 caso 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 instância do SignalR, você pode selecionar as métricas de Carga do Servidor para ver a "pressão" do 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 permanecerá baixa se a carga do servidor estiver abaixo de 70%.
Observação
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 do Azure SignalR.
Saída: a mensagem de saída do Serviço do 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 SignalR do Azure é 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 em que o Serviço do Azure SignalR aceita somente conexões de cliente. Nenhuma conexão de servidor é permitida.
Visão geral
O Serviço do 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 do 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 aplicativos (tamanho da VM) é adequado para mim? Quantos deles devo implantar?
Para responder essas perguntas, primeiro este guia traz uma explicação geral dos fatores que afetam o desempenho. Em seguida, ele ilustra o máximo de mensagens de entrada e de saída para cada camada para casos de uso típicos: eco, difusão, enviar para grupo e enviar para conexão (chat ponto a ponto).
O guia não pode abordar todos os cenários (nem diferentes casos de uso, tamanhos de mensagem, padrões de envio de mensagens e assim por diante). No entanto, ele fornece alguns métodos para ajudar você a:
- Avaliar os requisitos aproximados para as mensagens de entrada ou de saída.
- Localizar as camadas adequadas verificando a tabela de desempenho.
Insight de desempenho
Esta seção descreve as metodologias de avaliação de desempenho e lista todos os fatores que afetam o desempenho. No final, ela fornece métodos que ajudam a avaliar os requisitos de desempenho.
Metodologia
A taxa de transferência e a latência são dois aspectos típicos da verificação de desempenho. No Serviço do Azure SignalR, cada camada de SKU tem a 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 atingida quando 99% das mensagens têm latência inferior a 1 segundo.
Latência é o tempo decorrido do momento em que a conexão envia a mensagem ao momento em que recebe a mensagem de resposta do Serviço do Azure SignalR. Tomemos o eco como exemplo. Cada conexão de cliente adiciona um carimbo de data/hora à mensagem. O hub do servidor de aplicativos envia a mensagem original de volta ao cliente. Assim, o atraso da propagação é calculado facilmente por cada conexão de cliente. O carimbo de data/hora é anexado a cada mensagem nas camadas difusão, enviar para grupo e enviar para 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 do Azure SignalR.
No modo padrão do Serviço do Azure SignalR, as VMs do servidor de aplicativos são implantadas na mesma rede virtual privada que as VMs do cliente. Todas as VMs do cliente e VMs de servidor de aplicativos são implantadas na mesma rede da mesma região para evitar latência entre regiões.
Fatores de desempenho
Os fatores a seguir afetam o desempenho do SignalR.
- Camada do 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)
- Conectar do serviço e do servidor de aplicativos (no modo de servidor)
Recursos do computador
Teoricamente, a capacidade do Serviço SignalR do Azure é limitada por recursos de computação: CPU, memória e rede. Por exemplo, mais conexões com o Serviço do Azure SignalR 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 do 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 de 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 por push do servidor para o cliente.
- Long-Polling: Long-Polling requer que os clientes sondem periodicamente as informações do servidor por meio de uma solicitação HTTP.
Para a mesma API sob as mesmas condições, o WebSocket tem o melhor desempenho, Server-Sent-Event é mais lento e Long-Polling é o mais lento de todos. O Serviço do Azure SignalR recomenda o WebSocket por padrão.
Custo de roteamento de mensagens
O custo do roteamento de mensagens também limita o desempenho. O Serviço do Azure SignalR desempenha a função de roteador de mensagens, roteando 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. No entanto, para difusão, enviar para grupo e enviar para conexão, o Serviço do Azure SignalR precisa procurar as conexões de destino na estrutura de dados distribuída interna. Esse processamento extra usa mais CPU, memória e largura de banda da rede. Como resultado, o desempenho é mais lento.
No modo padrão, o servidor de aplicativos também pode se tornar um gargalo em determinados cenários. O SDK do Azure SignalR precisa invocar o hub enquanto mantém uma conexão dinâmica 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 e é entregue mais rápido que o JSON. No entanto, o MessagePack pode não aprimorar o desempenho. O desempenho do Serviço SignalR do Azure não é sensível a protocolos porque ele não decodifica a carga de mensagens durante o encaminhamento de mensagens de clientes para servidores ou vice-versa.
Encontrando um SKU adequado
Como avaliar a capacidade de entrada/saída ou descobrir qual camada é adequada para um caso de uso específico?
Suponha que o servidor de aplicativos seja poderoso o suficiente e não seja o gargalo de desempenho. Em seguida, verifique a largura de banda máxima de entrada e de 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 é 2.048 bytes.
- Uma mensagem é enviada por segundo.
- O Serviço do Azure SignalR está no modo padrão.
Cada camada tem a própria largura de banda máxima de entrada e 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.
Eco fornece a largura de banda de entrada máxima porque tem o menor custo de roteamento. Difusão define a largura de banda de mensagem de saída máxima.
Não exceda os valores realçados nas duas tabelas a seguir.
| Eco | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| conexõ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 |
| Broadcast | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| conexõ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 delas:
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 mensagem (valor médio). Uma mensagem pequena, com menos de 1.024 bytes, tem um impacto sobre o desempenho semelhante ao de uma mensagem de 1.024 bytes.
sendInterval: o tempo para o envio de uma mensagem. Normalmente, é de 1 segundo por mensagem, o que significa enviar uma mensagem a cada segundo. Um intervalo menor significa o envio de mais mensagens em um período. 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 do Azure SignalR para cada camada. Se o número de conexão for aumentado ainda mais, ele sofrerá com a limitação da conexão.
Observação
Você precisa escalar para SKU Premium_P2 ter tamanho de unidade maior que 100.
Avaliação de 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 tomar 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 difusão. Mas o tamanho da mensagem, a contagem de conexões e a taxa de envio de mensagens são diferentes do que presumimos na seção anterior. A questão é como deduzir um desses itens (tamanho da mensagem, contagem de conexões ou taxa de envio de mensagens) conhecendo apenas dois deles.
| Broadcast | Tamanho da mensagem | Mensagens de entrada simultâneas | conexões | Intervalos de envio |
|---|---|---|---|---|
| 1 | 20 KB | 1 | 100.000 | 5 segundos |
| 2 | 256 KB | 1 | 8,000 | 5 segundos |
A seguinte fórmula é 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 em relação à tabela anterior. Para um tamanho de mensagem de 20 KB, o máximo de conexões de saída precisa ser 400 MB * 5/20 KB = 100.000, que corresponde ao valor real.
Casos de uso mistos
O caso de uso real normalmente combina os quatro casos de uso básicos: eco, difusão, enviar para grupo e enviar para conexão. A metodologia usada para avaliar a capacidade é:
- Dividir os casos de uso mistos em quatro casos de uso básicos.
- Calcular a largura de banda máxima da mensagem de entrada e de saída usando as fórmulas anteriores separadamente.
- Somar os cálculos de largura de banda para obter a largura de banda máxima de entrada/saída.
Em seguida, selecionar a camada apropriada nas tabelas de largura de banda máxima de entrada/saída.
Observação
Para enviar uma mensagem para centenas ou milhares de pequenos grupos, ou no caso de milhares de clientes que enviam uma mensagem uns aos outros, o custo de roteamento se tornará dominante. Leve esse impacto em conta.
Para o caso de uso de enviar uma mensagem aos clientes, verifique se o servidor de aplicativos não é o afunilamento. A seção "Estudo de caso" a seguir fornece diretrizes sobre quantos servidores de aplicativos são necessários e quantas conexões de servidor devem ser configuradas.
Estudo de caso
As seções a seguir descrevem os quatro casos de uso típicos para o transporte WebSocket: eco, difusão, enviar para grupo e enviar para conexão. Para cada cenário, a seção lista a capacidade atual de entrada e de saída do Serviço do Azure SignalR. Ela 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 do Azure SignalR. O servidor de aplicativos usa o SDK do Serviço do Azure SignalR por padrão. Nos resultados do teste de desempenho a seguir, as conexões do servidor são aumentadas para 15 (ou mais nos casos de difusão e de envio de uma mensagem para um grupo grande).
Casos de uso diferentes têm requisitos diferentes para servidores de aplicativos. A difusão precisa de um número pequeno de servidores de aplicativos. Echo e enviar para conexão precisam de muitos servidores de aplicativos.
Em todos os casos de uso, o tamanho da mensagem padrão é 2.048 bytes e o intervalo de envio de mensagens é de 1 segundo.
Modo padrão
Clientes, servidores de aplicativos Web e o Serviço do Azure SignalR estão envolvidos no modo padrão. Cada cliente representa uma conexão.
Eco
Primeiro, um aplicativo Web se conecta ao Serviço do Azure SignalR. Depois, muitos clientes se conectam ao aplicativo Web, que os redireciona para o Serviço do Azure SignalR com o token de acesso e o ponto de extremidade. Em seguida, os clientes estabelecem conexões WebSocket com o Serviço do 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 para o 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 realçado em vermelho) estão em um loop. O loop é executado por um período padrão (5 minutos) e obtém a estatística de latência de todas as mensagens.
O comportamento do eco determina que a largura de banda de entrada máxima é igual à largura de banda de saída máxima. 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 |
|---|---|---|---|---|---|---|---|---|
| conexõ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 de aplicativos. O hub apenas chama o método definido no lado do cliente original. Esse hub é o mais leve para o eco.
public void Echo(IDictionary<string, object> data)
{
Clients.Client(Context.ConnectionId).SendAsync("RecordLatency", data);
}
Mesmo para esse hub simples, a pressão do tráfego sobre o servidor de aplicativos fica proeminente à medida que a carga de mensagens de entrada de eco aumenta. Essa pressão do tráfego requer muitos servidores de aplicativos para camadas de SKU grandes. A tabela a seguir lista a contagem de servidores de aplicativos para cada camada.
| Eco | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| conexões | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1\.000.000 |
| Contagem de servidores de aplicativos | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Observação
O número de conexões de cliente, o tamanho da mensagem, a taxa de envio de mensagens, a camada do SKU e a CPU/memória do servidor de aplicativos afetam o desempenho geral do eco.
Broadcast
Para a difusão, quando o aplicativo Web recebe a mensagem, ele a difunde para todos os clientes. Quanto mais clientes houver para transmitir, mais tráfego de mensagens haverá para todos os clientes. Confira o diagrama a seguir.
Um número pequeno de clientes está difundindo. 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 de cliente ou a taxa de difusã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.
| Broadcast | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| conexõ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 difusão que postam mensagens não passam de quatro. Eles precisam de menos servidores de aplicativos em comparação com eco porque a quantidade de mensagens de entrada é pequena. Dois servidores de aplicativos são suficientes em termos de desempenho e do SLA. Mas você deve aumentar as conexões de servidor padrão para evitar desequilíbrio, especialmente para Unidade maior que 50.
| Broadcast | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| conexões | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1\.000.000 |
| Contagem de servidores de aplicativos | 1 | 1 | 1 | 2 | 2 | 4 | 10 | 20 |
Observação
Aumente as conexões de servidor padrão de 5 para 40 em cada servidor de aplicativos para evitar possíveis conexões de servidor desbalanceadas com o Serviço do Azure SignalR.
O número de conexões de cliente, o tamanho da mensagem, a taxa de envio de mensagens e a camada do SKU afetam o desempenho geral da difusão.
Enviar para grupo
O caso de uso de enviar para grupo tem um padrão de tráfego semelhante ao de difusão. A diferença é que, após os clientes estabelecerem conexões WebSocket com o Serviço do Azure SignalR, eles devem ingressar em grupos antes que possam enviar uma mensagem a um grupo específico. O seguinte diagrama ilustra esse fluxo de tráfego.
Os membros do grupo e a contagem de grupos 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 de grupos é igual a (contagem máxima de conexões)/10. Por exemplo, para a Unidade 1, se houver 1.000 contagens de conexão, teremos 1000 / 10 = 100 grupos.
Grupo grande: o número de grupos é sempre 10. A contagem de membros do grupo é igual a (contagem máxima de conexões)/10. Por exemplo, para a Unidade 1, se houver 1.000 contagens de conexão, cada grupo terá 1000 / 10 = 100 membros.
Enviar para grupo traz um custo de roteamento para o Serviço do Azure SignalR porque precisa localizar 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 a muitos grupos pequenos. Atualmente, a implementação do Serviço SignalR do Azure 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 atendimento ao cliente.
| Enviar para grupo pequeno | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| conexõ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 de servidores de aplicativos também é crítico para o desempenho. A tabela a seguir lista as contagens sugeridas de servidores de aplicativos.
| Enviar para grupo pequeno | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| conexões | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1\.000.000 |
| Contagem de servidores de aplicativos | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Observação
O número de conexões de cliente, o tamanho da mensagem, a taxa de envio de mensagens, o custo de roteamento, a camada do SKU e a CPU/memória do servidor de aplicativos afetam o desempenho geral de enviar para grupo pequeno.
A contagem de grupos, a contagem de membros do grupo listadas na tabela não são limites rígidos. Esses valores de parâmetro são selecionados para estabelecer um cenário de benchmark estável. Por exemplo, não há problema em atribuir cada conexão a um grupo distinto. Nessa configuração, o desempenho é próximo para enviar para a conexão.
Grupo grande
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 de saída máxima, que é quase igual à de difusão.
| Enviar para grupo grande | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| conexõ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 passa de 40. A carga sobre o 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 |
|---|---|---|---|---|---|---|---|---|
| conexões | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1\.000.000 |
| Contagem de servidores de aplicativos | 1 | 1 | 2 | 2 | 2 | 4 | 10 | 20 |
Observação
Aumente as conexões de servidor padrão de 5 para 40 em cada servidor de aplicativos para evitar possíveis conexões de servidor desbalanceadas com o Serviço do Azure SignalR.
O número de conexões de cliente, o tamanho da mensagem, a taxa de envio de mensagens, o custo de roteamento e a camada do SKU afetam o desempenho geral de enviar para 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 do Azure SignalR, cada cliente chama um hub especial para obter a própria ID de conexão. O parâmetro de comparação de desempenho coleta todas as IDs de conexão, as embaralha e as 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 seja concluído.
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 aprimora os recursos de roteamento.
A tabela a seguir é um resumo estatístico após muitas rodadas da execução do parâmetro de comparação de enviar para conexão.
| Enviar para conexão | Unidade 1 | Unidade 2 | Unidade 20 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| conexõ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 |
Observação
Apesar da estagnação nas mensagens de entrada/saída por segundo após a Unidade 20, a capacidade de mais conexões continua a crescer. Em cenários de negócios reais, geralmente é a contagem de conexões, não sua atividade simultânea de envio de mensagens, que forma o gargalo. É incomum que todas as conexões estejam enviando mensagens ativamente em frequências tão altas quanto o teste de benchmark.
Esse caso de uso requer uma carga alta no lado do servidor de aplicativos. Veja as contagens de servidores de aplicativos sugeridas na tabela a seguir.
| Enviar para conexão | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| conexões | 1.000 | 2.000 | 10.000 | 50.000 | 100.000 | 200.000 | 500.000 | 1\.000.000 |
| Contagem de servidores de aplicativos | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Observação
O número de conexões de cliente, o tamanho da mensagem, a taxa de envio de mensagens, o custo de roteamento, a camada do SKU e a CPU/memória do servidor de aplicativos afetam o desempenho geral de enviar para conexão.
ASP.NET SignalR
O Serviço do Azure SignalR fornece a mesma capacidade de desempenho para o ASP.NET SignalR.
Modo sem servidor
Os clientes e o Serviço do Azure SignalR estão envolvidos no modo sem servidor. Cada cliente representa uma conexão. O cliente envia mensagens por meio da API REST para outro cliente ou difunde mensagens para todos.
O envio de mensagens de alta densidade por meio da API REST não é tão eficiente quanto usar o WebSocket. Ele exige que você crie uma conexão HTTP a cada vez, o que é um custo extra no modo sem servidor.
Difusão por meio da API REST
Todos os clientes estabelecem conexões WebSocket com o Serviço do Azure SignalR. Em seguida, alguns clientes iniciam a difusão por meio da API REST. O envio de mensagens (entrada) é todo através de HTTP Post, que não é eficiente em comparação com o WebSocket.
| Difusão por meio da API REST | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| conexõ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 usuário via API REST
O parâmetro de comparação atribui nomes de usuários a todos os clientes antes que eles comecem a se conectar ao Serviço do Azure SignalR. Depois que os clientes estabelecem conexões WebSocket com o Serviço do Azure SignalR, eles começam a enviar mensagens para outras pessoas via HTTP Post.
| Enviar para usuário via API REST | Unidade 1 | Unidade 2 | Unidade 10 | Unidade 50 | Unidade 100 | Unidade 200 | Unidade 500 | Unidade 1000 |
|---|---|---|---|---|---|---|---|---|
| conexõ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, realizamos os testes de desempenho em um ambiente do Azure. No máximo, usamos 200 VMs de cliente e 100 VMs de servidor de aplicativo. Aqui estão alguns detalhes:
Tamanho da VM de cliente: StandardDS2V2 (2 vCPUs, memória de 7 G)
Tamanho da VM do servidor de aplicativos: StandardF4sV2 (4 vCPUs, memória de 8 G)
Conexões de servidor do SDK do Azure SignalR: 15
Ferramentas de desempenho
Você pode encontrar ferramentas de desempenho para o Serviço do Azure SignalR no GitHub.
Próximas etapas
Neste artigo, você teve uma visão geral do desempenho do Serviço do Azure SignalR em cenários de caso de uso típicos.
Para obter detalhes sobre os elementos internos do serviço e a colocação em escala para ele, leia os seguintes guias: