Share via


Guia de desempenho do Serviço Azure Web PubSub

Um dos principais benefícios do uso do serviço Azure Web PubSub é a facilidade de colocação em escala. Em um cenário de grande escala, o desempenho é um fator importante.

Neste guia, apresentamos os fatores que afetam o desempenho do serviço Web PubSub. Descrevemos o desempenho típico em diferentes cenários de caso de uso.

Avaliação rápida usando métricas

Antes de passar pelos fatores que afetam o desempenho, vamos primeiro apresentar uma maneira fácil de monitorar a pressão do serviço. Há uma métrica chamada Carga do servidor no portal.

Captura de tela da métrica de carregamento do servidor do Azure Web PubSub no portal. A métrica mostra que a carga do servidor está em cerca de 8% de uso.

Ela mostra a pressão de computação do serviço Azure Web PubSub. Você pode testar em seu próprio cenário e verificar essa métrica para decidir se deseja escalar verticalmente. A latência dentro do serviço Azure Web PubSub 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), você precisará conferir envio para grupos pequenos para referência. Nesses cenários, há um grande custo de roteamento que não está incluído na Carga do Servidor.

Veja abaixo conceitos detalhados sobre a avaliação de desempenho.

Definições de termos

Entrada: a mensagem de entrada para o Serviço do Azure Web PubSub.

Saída: a mensagem de saída do Serviço Azure Web PubSub.

Largura de banda: o tamanho total de todas as mensagens em 1 segundo.

Visão geral

Este guia responde às seguintes perguntas:

  • Qual é o desempenho típico do serviço Azure Web PubSub para cada tamanho de unidade?

  • O Serviço Azure Web PubSub atende a 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 o tamanho da unidade adequado?

Para responder essas perguntas, primeiro este guia traz uma explicação geral dos fatores que afetam o desempenho. Em seguida, ele ilustra a entrada e saída de mensagens máxima para casos de uso típicos: Enviar para grupos por meio de subprotocolo Web PubSub, upstream e API REST.

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). Mas ele fornece algumas informações básicas para entender a limitação 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. A taxa de transferência máxima (largura de banda de entrada e saída) é definida como a taxa de transferência máxima alcançada quando 99% das mensagens têm latência inferior a 1 segundo. Não é um limite rígido.

Fatores de desempenho

Teoricamente, a capacidade do Serviço Azure Web PubSub é limitada pelos recursos de computação: CPU, memória e rede. Por exemplo, mais conexões com o Serviço Azure Web PubSub 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 Web PubSub precisa gastar mais ciclos de CPU para processar o tráfego.

O custo do roteamento de mensagens também limita o desempenho. O Serviço Azure Web PubSub desempenha uma função como agente de mensagem, que roteia a mensagem entre um conjunto de clientes. Um cenário ou API diferente requer uma política de roteamento diferente.

Para Echo, o cliente envia uma mensagem para o upstream e o upstream ecoa a mensagem de volta para o cliente. Esse padrão tem o menor custo de roteamento. No entanto, para transmitir, enviar para grupo e enviar para conexão, o Serviço Azure Web PubSub 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.

Em resumo, os seguintes fatores afetam a capacidade de entrada e de saída:

  • Tamanho da unidade (CPU/memória)

  • Número de conexões

  • Tamanho da mensagem

  • Taxa de envio de mensagens

  • Cenário de caso de uso (custo de roteamento)

Localizar um tamanho de unidade adequado

Como você pode avaliar a capacidade de entrada/saída ou encontrar qual tamanho de unidade é adequado para um caso de uso específico?

Cada tamanho de unidade tem sua própria largura de banda de entrada e largura de banda de saída máximas. Uma experiência do usuário tranquila não é garantida depois que o tráfego de entrada ou saída excede o limite.

  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 intervalo para enviar mensagens. Por exemple, 1 segundo significa enviar uma mensagem a cada segundo. Um intervalo menor significa enviar mais mensagens em um período. Por exemplo, 0,5 segundos significa enviar duas mensagens a cada segundo.
  • Conexões: o limite máximo confirmado para o serviço do Azure Web PubSub para cada tamanho de unidade. As conexões que excedem o limite são restritas.

Suponha que o upstream seja eficiente o suficiente e não seja o gargalo de desempenho. Em seguida, verifique a largura de banda máxima de entrada e saída para cada tamanho de unidade.

Estudo de caso

As seções a seguir passam por três casos de uso típicos: enviar para grupos por meio do subprotocolo Web PubSub, disparar CloudEvent, chamar API REST. Para cada cenário, a seção lista a capacidade atual de entrada e de saída do Serviço Azure Web PubSub. Ela também explica os principais fatores que afetam o desempenho.

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.

Enviar para grupos por meio do subprotocolo Web PubSub

O serviço dá suporte a um subprotocolo específico chamado json.webpubsub.azure.v1, que permite que os clientes publiquem/assinem diretamente, em vez de haver uma viagem de ida e volta para o servidor upstream. Esse cenário é eficiente, pois nenhum servidor está envolvido e todo o tráfego passa pela conexão WebSocket do serviço cliente.

Diagrama mostrando o fluxo de trabalho de enviar para grupo.

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 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.
  • 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.

Enviar para grupo traz um custo de roteamento para o Serviço Azure Web PubSub 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 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 máxima.

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 1.000 5.000 10,000 5.000 10,000 20,000
Contagem de grupos 10 10 10 10 10 10 10 10
Mensagens de entrada por segundo 30 30 30 30 30 30 30 30
Largura de banda de entrada 60 Kbps 60 Kbps 60 Kbps 60 Kbps 60 Kbps 60 Kbps 60 Kbps 60 Kbps
Mensagens de saída por segundo 3.000 6.000 30,000 150.000 300.000 600.000 1\.500.000 3.000.000
Largura de banda de saída 6 MBps 12 MBps 60 MBps 300 MBps 600 MBps 1.200 MBps 3.000 MBps 6.000 MBps
Grupo pequeno

O custo de roteamento é significativo para enviar mensagens a muitos grupos pequenos. Atualmente, a implementação do Serviço Azure Web PubSub atinge o limite de custo de roteamento na Unidade 50. Adicionar mais CPU e memória não ajuda; portanto, a Unidade 100 não pode melhorar ainda mais, por definição. Se você precisar de mais largura de banda de entrada, precisará escalar verticalmente para usar Premium_P2(unidade >100).

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

Observação

A contagem de grupos, contagem de membros de grupo listada na tabela não são limites rígidos. Esses valores de parâmetro são selecionados para estabelecer um cenário de parâmetro de comparação estável.

Disparar Evento de nuvem

O serviço fornece eventos de cliente para o webhook upstream usando o protocolo HTTP CloudEvents.

O Webhook de upstream

Para cada evento, ele formula uma solicitação HTTP POST para o upstream registrado e espera uma resposta HTTP.

Observação

O Web PubSub também dá suporte a HTTP 2.0 para eventos upstream de entrega. O resultado abaixo é testado usando HTTP 1.1. Se o seu servidor de aplicativos der suporte a HTTP 2.0, o desempenho será melhor.

Eco

Nesse caso, o servidor de aplicativos grava novamente a mensagem original na resposta http. O comportamento do eco determina que a largura de banda de entrada máxima é igual à largura de banda de saída máxima. Para ver detalhes, confira 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 500 1,000 5.000 25.000 50.000 100.000 250.000 500.000
Largura de banda de entrada/saída 1 MBps 2 MBps 10 MBps 50 MBps 100 MBps 200 MBps 500 MBps 1.000 MBps

API REST

O Azure Web PubSub fornece APIs poderosas para gerenciar clientes e fornecer mensagens em tempo real.

Diagrama mostrando o fluxo de trabalho geral do serviço Web PubSub usando APIs REST.

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 Azure Web PubSub.

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 180 360 1.800 9.000 18.000 36.000 90.000 180,000
Largura de banda de entrada/saída 360 KBps 720 KBps 3,6 MBps 18 MBps 36 MBps 72 MBps 180 MBps 360 MBps

Difusão por meio da API REST

A largura de banda é a mesma para enviar para um grande grupo.

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 3 3 3 3 3 3 3 3
Mensagens de saída por segundo 3.000 6.000 30,000 150.000 300.000 600.000 1\.500.000 3.000.000
Largura de banda de entrada 6 KBps 6 KBps 6 KBps 6 KBps 6 KBps 6 KBps 6 KBps 6 KBps
Largura de banda de saída 6 MBps 12 MBps 60 MBps 300 MBps 600 MBps 1.200 MBps 3.000 MB 6.000 MB

Próximas etapas

Use estes recursos para começar a criar seu aplicativo: