Guía de rendimiento del servicio Azure Web PubSub
Una de las principales ventajas de usar el servicio Azure Web PubSub es la facilidad de escalado. En un escenario a gran escala, el rendimiento es un factor importante.
En esta guía, se presentan los factores que afectan al rendimiento del servicio Web PubSub. Se describe el rendimiento típico en diferentes escenarios de casos de uso.
Evaluación rápida mediante métricas
Antes de examinar los factores que afectan al rendimiento, primero se presentará una manera sencilla de supervisar la presión del servicio. Hay una métrica denominada Server Load en el portal.
Muestra la presión de computación del servicio Azure Web PubSub. Puede probar en su propio escenario y comprobar esta métrica para decidir si se debe escalar verticalmente. La latencia dentro del servicio Azure Web PubSub seguirá siendo baja si la carga del servidor es inferior al 70 %.
Nota:
Si usa la unidad 50 o más y su escenario se envía principalmente a grupos pequeños (tamaño de grupo <20), necesitará comprobar enviar a grupos pequeños como referencia. En esos escenarios hay un gran coste de enrutamiento que no se incluye en la carga del servidor.
A continuación se muestran conceptos detallados para evaluar el rendimiento.
Definiciones de términos
Entrante: el mensaje entrante al servicio Azure Web PubSub.
Saliente: el mensaje saliente del servicio Azure Web PubSub.
Ancho de banda: el tamaño total de todos los mensajes en 1 segundo.
Información general
En esta guía se responden las preguntas siguientes:
¿Cuál es el rendimiento típico del servicio Azure Web PubSub para cada tamaño de unidad?
¿El servicio Azure Web PubSub cumple mis requisitos de rendimiento de mensajes (por ejemplo, envío de 100 000 mensajes por segundo)?
Para mi escenario específico, ¿cómo puedo seleccionar el tamaño de unidad adecuado?
Para responder estas preguntas, en esta guía primero se proporciona una explicación detallada de los factores que afectan al rendimiento. A continuación, muestra el número máximo de mensajes entrantes y salientes para casos de uso típicos: Enviar a grupos a través de subprotocolos de Web PubSub, ascendente, y API de Rest.
En esta guía no se pueden tratar todos los escenarios (ni casos de uso, tamaños de mensaje, patrones de envío de mensajes, etc. diferentes). Pero proporciona información básica para comprender las limitaciones de rendimiento.
Conclusión sobre el rendimiento
En esta sección se describen las metodologías de evaluación del rendimiento y luego se enumeran todos los factores que afectan al rendimiento. Al final, se proporcionan métodos para ayudarle a evaluar los requisitos de rendimiento.
Metodología
El rendimiento y la latencia son dos aspectos típicos de la comprobación del rendimiento. El rendimiento máximo (ancho de banda entrante y saliente) se define como el rendimiento máximo alcanzado cuando el 99 % de los mensajes tienen latencia inferior a 1 segundo. No es un límite estricto.
Factores de rendimiento
En teoría, la capacidad del servicio Azure Web PubSub se ve limitada por los recursos de cálculo: CPU, memoria y red. Por ejemplo, un mayor número de conexiones al servicio Azure Web PubSub hace que el servicio use más memoria. Para mayor tráfico de mensajes (por ejemplo, cada mensaje es mayor que 2048 bytes), el servicio Azure Web PubSub debe dedicar más ciclos de CPU para procesar el tráfico.
El costo de enrutamiento de mensajes también limita el rendimiento. El servicio Azure Web PubSub desempeña un papel como agente de mensajes, que enruta el mensaje entre un conjunto de clientes. Un escenario o API diferente requiere una directiva de enrutamiento diferente.
Para echo, el cliente envía un mensaje al servidor ascendente, y este devuelve el mensaje al cliente. Este patrón tiene el menor costo de enrutamiento. Sin embargo, para difusión, enviar al grupo y enviar a conexión, el servicio Azure Web PubSub debe buscar las conexiones de destino a través de la estructura de datos internos distribuidos. Este procesamiento adicional usa más recursos de la CPU, memoria y ancho de banda de red. Como resultado, el rendimiento es más lento.
En resumen, los siguientes factores afectan a la capacidad de entrada y salida:
Tamaño de unidad (CPU/memoria)
Número de conexiones
Tamaño del mensaje
Velocidad de envío de mensajes
Escenario de caso de uso (costo de enrutamiento)
Búsqueda de un tamaño de unidad adecuado
¿Cómo puede evaluar la capacidad de entrada o salida o encontrar qué tamaño de unidad es adecuado para un caso de uso específico?
Cada tamaño de unidad tiene su propio ancho de banda de entrada máximo y ancho de banda saliente. No se garantiza una experiencia de usuario fluida después de que el tráfico entrante o saliente supere el umbral.
inboundBandwidth = inboundConnections * messageSize / sendInterval
outboundBandwidth = outboundConnections * messageSize / sendInterval
- inboundConnections: el número de conexiones que envían el mensaje.
- outboundConnections: el número de conexiones que reciben el mensaje.
- messageSize: el tamaño de un único mensaje (valor medio). Un mensaje pequeño de menos de 1024 bytes tiene un impacto sobre el rendimiento que es similar a un mensaje de 1024 bytes.
- sendInterval:el intervalo para enviar mensajes. Por ejemplo, 1 segundo significa que se envía un mensaje cada segundo. Un intervalo más pequeño significa enviar más mensajes en un período de tiempo. Por ejemplo, 0,5 segundos significa enviar dos mensajes cada segundo.
- Conexiones: el umbral máximo confirmado para el servicio Azure Web PubSub para cada tamaño de unidad. Se limitan las conexiones que superan el umbral.
Suponga que el servidor ascendente es lo suficientemente eficaz y no es el cuello de botella del rendimiento. A continuación, compruebe el ancho de banda de entrada y salida máximo para cada tamaño de unidad.
Caso práctico
Las secciones siguientes pasan por tres casos de uso típicos: envío a grupos a través del subprotocolo de Web PubSub, desencadenamiento de CloudEventy llamada API REST. Para cada escenario, en la sección se muestra la capacidad actual de entrada y salida para el servicio Azure Web PubSub. También se explican los principales factores que afectan al rendimiento.
En todos los casos de uso, el tamaño predeterminado de mensaje es 2048 bytes y el intervalo de envío de mensajes es 1 segundo.
Envío a grupos a través del subprotocolo Web PubSub
El servicio admite un subprotocolo específico denominado json.webpubsub.azure.v1, que permite a los clientes publicar o suscribirse directamente en lugar de realizar un recorrido de ida y vuelta al servidor ascendente. Este escenario es eficaz, ya que no hay ningún servidor involucrado, y todo el tráfico pasa a través de la conexión WebSocket del servicio cliente.
Los miembros de grupo y el número de grupos son dos factores que afectan al rendimiento. Para simplificar el análisis, se definen dos tipos de grupos:
- Grupo grande: el número de grupos es siempre 10. El número de miembros del grupo es igual a (número máximo de conexiones) / 10. Por ejemplo, para unidad 1, si hay 1000 recuentos de conexiones, cada grupo tiene 1000 / 10 = 100 miembros.
- Grupo pequeño: cada grupo tiene 10 conexiones. El número de grupos es igual a (número máximo de conexiones) / 10. Por ejemplo, para unidad 1, si hay 1000 recuentos de conexiones, tenemos 1000 / 10 = 100 grupos.
Enviar al grupo agrega un costo de enrutamiento al servicio Azure Web PubSub porque debe buscar las conexiones de destino a través de una estructura de datos distribuidos. A medida que aumentan las conexiones de envío, aumenta el coste.
Grupo grande
Para enviar a grupo grande, el ancho de banda saliente se convierte en el cuello de botella antes de alcanzar el límite de coste de enrutamiento. En la tabla siguiente se enumera el ancho de banda de salida máximo.
| Enviar a grupo grande | Unidad 1 | Unidad 2 | Unidad 10 | Unidad 50 | Unidad 100 | Unidad 200 | Unidad 500 | Unidad 1000 |
|---|---|---|---|---|---|---|---|---|
| Conexiones | 1,000 | 2.000 | 10 000 | 50.000 | 100 000 | 200 000 | 500.000 | 1 000 000 |
| Número de miembros del grupo | 100 | 200 | 1,000 | 5\.000 | 10 000 | 5\.000 | 10 000 | 20.000 |
| Número de grupos | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Mensajes entrantes por segundo | 30 | 30 | 30 | 30 | 30 | 30 | 30 | 30 |
| Ancho de banda entrante | 60 kbps | 60 kbps | 60 kbps | 60 kbps | 60 kbps | 60 kbps | 60 kbps | 60 kbps |
| Mensajes salientes por segundo | 3,000 | 6,000 | 30,000 | 150 000 | 300 000 | 600 000 | 1 500 000 | 3 000 000 |
| Ancho de banda saliente | 6 Mbps | 12 Mbps | 60 Mbps | 300 Mbps | 600 Mbps | 1,200 Mbps | 3,000 Mbps | 6,000 Mbps |
Grupo pequeño
El coste de enrutamiento es importante para enviar mensajes a muchos grupos pequeños. Actualmente, la implementación del servicio Azure Web PubSub alcanza el límite de costos de enrutamiento en Unidad50. Agregar más CPU y memoria no ayuda, por lo que la unidad 100 no puede mejorar aún más por diseño. Si necesita más ancho de banda de entrada, debe escalar verticalmente para usar Premium_P2(unidad >100).
| Enviar a un grupo pequeño | Unidad 1 | Unidad 2 | Unidad 10 | Unidad 50 | Unidad 100 | Unidad 200 | Unidad 500 | Unidad 1000 |
|---|---|---|---|---|---|---|---|---|
| Conexiones | 1,000 | 2.000 | 10 000 | 50.000 | 100 000 | 200 000 | 500.000 | 1 000 000 |
| Número de miembros del grupo | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Número de grupos | 100 | 200 | 1,000 | 5\.000 | 10 000 | 20.000 | 50.000 | 100 000 |
| Mensajes entrantes por segundo | 200 | 400 | 2 000 | 10,000 | 10 000 | 20.000 | 50.000 | 100 000 |
| Ancho de banda entrante | 400 Kbps | 800 Kbps | 4 MBps | 20 MBps | 20 MBps | 40 MBps | 100 MBps | 200 MBps |
| Mensajes salientes por segundo | 2\.000 | 4\.000 | 20.000 | 100 000 | 100 000 | 200 000 | 500.000 | 1 000 000 |
| Ancho de banda saliente | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 200 MBps | 400 MBps | 1000 MBps | 2000 MBps |
Nota:
El recuento de grupos, el recuento de miembros del grupo que se muestra en la tabla no límites estrictos. Estos valores de parámetro se seleccionan para establecer un escenario de prueba comparativa estable.
Desencadenamiento de eventos en la nube
El servicio entrega eventos de cliente al webhook ascendente mediante el protocolo HTTP CloudEvents.
Para cada evento, formula una solicitud HTTP POST al servidor ascendente registrado y espera una respuesta HTTP.
Nota:
Web PubSub también admite HTTP 2.0 para la entrega de eventos ascendentes. El resultado siguiente se prueba con HTTP 1.1. Si su servidor de aplicaciones admite HTTP 2.0, el rendimiento será mejor.
Echo
En este caso, el servidor de aplicaciones vuelve a escribir el mensaje original en la respuesta HTTP. El comportamiento de eco determina que el ancho de banda entrante máximo es igual que el ancho de banda saliente máximo. Consulte la tabla siguiente para más detalles:
| Echo | Unidad 1 | Unidad 2 | Unidad 10 | Unidad 50 | Unidad 100 | Unidad 200 | Unidad 500 | Unidad 1000 |
|---|---|---|---|---|---|---|---|---|
| Conexiones | 1,000 | 2.000 | 10 000 | 50.000 | 100 000 | 200 000 | 500.000 | 1 000 000 |
| Mensajes entrantes y salientes por segundo | 500 | 1,000 | 5,000 | 25 000 | 50.000 | 100 000 | 250 000 | 500.000 |
| Ancho de banda entrante y saliente | 1 Mbps | 2 MBps | 10 MBps | 50 Mbps | 100 MBps | 200 MBps | 500 Mbps | 1000 MBps |
REST API
Azure Web PubSub brinda API eficaces para administrar clientes y entregar mensajes en tiempo real.
Enviar al usuario a través de la API de REST
El banco de pruebas asigna nombres de usuario a todos los clientes antes de estos empiecen a conectarse al servicio Azure Web PubSub.
| Enviar al usuario a través de la API de REST | Unidad 1 | Unidad 2 | Unidad 10 | Unidad 50 | Unidad 100 | Unidad 200 | Unidad 500 | Unidad 1000 |
|---|---|---|---|---|---|---|---|---|
| Conexiones | 1,000 | 2.000 | 10 000 | 50.000 | 100 000 | 200 000 | 500.000 | 1 000 000 |
| Mensajes entrantes y salientes por segundo | 180 | 360 | 1800 | 9000 | 18 000 | 36 000 | 90 000 | 180,000 |
| Ancho de banda entrante y saliente | 360 kbps | 720 kbps | 3,6 Mbps | 18 Mbps | 36 Mbps | 72 Mbps | 180 Mbps | 360 Mbps |
Difusión a través de la API de REST
El ancho de banda es el mismo que para enviar al grupo grande.
| Difusión a través de la API de REST | Unidad 1 | Unidad 2 | Unidad 10 | Unidad 50 | Unidad 100 | Unidad 200 | Unidad 500 | Unidad 1000 |
|---|---|---|---|---|---|---|---|---|
| Conexiones | 1,000 | 2.000 | 10 000 | 50.000 | 100 000 | 200 000 | 500.000 | 1 000 000 |
| Mensajes entrantes por segundo | 3 | 3 | 3 | 3 | 3 | 3 | 3 | 3 |
| Mensajes salientes por segundo | 3,000 | 6,000 | 30,000 | 150 000 | 300 000 | 600 000 | 1 500 000 | 3 000 000 |
| Ancho de banda entrante | 6 kbps | 6 kbps | 6 kbps | 6 kbps | 6 kbps | 6 kbps | 6 kbps | 6 kbps |
| Ancho de banda saliente | 6 Mbps | 12 Mbps | 60 Mbps | 300 Mbps | 600 Mbps | 1200 Mbps | 3000 MB | 6000 MB |
Pasos siguientes
Use estos recursos para empezar a compilar su propia aplicación:
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de