Guía de rendimiento para Azure SignalR Service
Una de las principales ventajas de usar Azure SignalR Service es la facilidad de escalado de las aplicaciones de SignalR. En un escenario a gran escala, el rendimiento es un factor importante.
En este artículo se describe:
- Factores que afectan al rendimiento de la aplicación SignalR.
- El rendimiento típico en diferentes escenarios de casos de uso.
- Entorno y herramientas que puede usar para generar un informe de rendimiento.
Evaluación rápida mediante métricas
Puede supervisar fácilmente el servicio en Azure Portal. En la página Métricas de la instancia de SignalR, puede seleccionar las métricas de carga del servidor para ver la "presión" del servicio.
El gráfico muestra la presión informática del servicio SignalR. Puede probar el escenario y comprobar esta métrica para decidir si se debe escalar verticalmente. La latencia dentro del servicio SignalR sigue siendo baja si la carga del servidor está por debajo del 70 %.
Nota:
Si usa la unidad 50 o superior y su escenario se envía principalmente a grupos pequeños (tamaño <de grupo 20) o una sola conexión, debe comprobar el envío a un grupo pequeño o el envío a la conexión como referencia. En esos escenarios hay un gran coste de enrutamiento que no se incluye en la carga del servidor.
Definiciones de términos
Entrante: el mensaje entrante a Azure SignalR Service.
Saliente: el mensaje saliente de Azure SignalR Service.
Ancho de banda: el tamaño total de todos los mensajes en 1 segundo.
Modo predeterminado: modo de trabajo predeterminado cuando se crea una instancia de Azure SignalR Service. Azure SignalR Service espera que el servidor de aplicaciones establezca una conexión con él antes de aceptar cualquier conexión de cliente.
Modo sin servidor: modo en que Azure SignalR Service acepta únicamente conexiones de cliente. No se permite ninguna conexión de servidor.
Información general
Azure SignalR Service define siete niveles estándar para distintas capacidades de rendimiento. En esta guía se responden las preguntas siguientes:
¿Cuál es el rendimiento típico de Azure SignalR Service para cada nivel (unidad)?
¿Azure SignalR Service 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 nivel adecuado?
¿Qué tipo de servidor de aplicaciones (tamaño de VM) es adecuado para mí? ¿Cuántos debo implementar?
Para responder estas preguntas, en esta guía primero se proporciona una explicación detallada de los factores que afectan al rendimiento. Luego, se muestra el número máximo de mensajes entrantes y salientes de cada nivel para casos de uso típicos: eco, difusión, enviar al grupo y enviar a conexión (chats punto a punto).
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). Sin embargo, se proporcionan algunos métodos para ayudarle a hacer lo siguiente:
- Evaluar los requisitos aproximados de los mensajes entrantes o salientes.
- Encontrar los niveles adecuados mediante la comprobación de la tabla 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. Para Azure SignalR Service, cada nivel de SKU tiene su propia directiva de limitación de rendimiento. La directiva define el rendimiento máximo permitido (ancho de banda entrante y saliente) como el rendimiento máximo obtenido cuando el 99 % de los mensajes tiene una latencia menor que 1 segundo.
La latencia es el intervalo de tiempo entre que la conexión envía el mensaje hasta recibir el mensaje de respuesta de Azure SignalR Service. Tome eco como ejemplo. Cada conexión de cliente agrega una marca de tiempo en el mensaje. El centro del servidor de aplicaciones envía el mensaje original de nuevo al cliente. Por lo tanto, el retraso de propagación la calcula fácilmente cada conexión de cliente. La marca de tiempo se adjunta para todos los mensajes de difusión, enviar al grupo y enviar a conexión.
Para simular miles de conexiones de cliente simultáneas, se crean varias VM en una red privada virtual en Azure. Todas estas VM se conectan a la misma instancia de Azure SignalR Service.
En el modo predeterminado de Azure SignalR Service, las VM del servidor de aplicaciones se implementan en la misma red privada virtual como VM de cliente. Todas las Cm de cliente y VM de servidor de aplicaciones se implementan en la misma red de la misma región para evitar una latencia entre regiones.
Factores de rendimiento
Los siguientes factores afectan al rendimiento de SignalR.
- Nivel de SKU (CPU y memoria)
- Número de conexiones
- Tamaño del mensaje
- Velocidad de envío de mensajes
- Tipo de transporte (WebSocket, evento enviado de servidor o sondeo largo)
- Escenario de caso de uso (costo de enrutamiento)
- Conexiones de servidor de aplicaciones y servicio (en modo de servidor)
Recursos de equipo
En teoría, la capacidad de Azure SignalR Service está limitada por recursos de proceso: CPU, memoria y red. Por ejemplo, un mayor número de conexiones a Azure SignalR Service hace que el servicio use más memoria. Para mayor tráfico de mensajes (por ejemplo, cada mensaje es mayor que 2048 bytes), para procesar el tráfico Azure SignalR Service debe dedicar más ciclos de CPU. Mientras tanto, el ancho de banda de red de Azure también impone un límite para el tráfico máximo.
Tipo de transporte
El tipo de transporte es otro factor que afecta al rendimiento. Los tres tipos son:
- WebSocket: WebSocket es un protocolo de comunicación bidireccional y dúplex completo a través de una única conexión TCP.
- Server-Sent-Event: Server-Sent-Event es un protocolo unidireccional para insertar mensajes del servidor al cliente.
- Sondeo largo: el sondeo largo requiere que los clientes sondee periódicamente la información del servidor a través de una solicitud HTTP.
Para la misma API en las mismas condiciones, WebSocket tiene el mejor rendimiento, eventos enviados del servidor es más lento y el sondeo largo es el más lento de los tres. Para Azure SignalR Service, se recomienda usar WebSocket de forma predeterminada.
Costo de enrutamiento de mensajes
El costo de enrutamiento de mensajes también limita el rendimiento. Azure SignalR Service desempeña un papel como enrutador de mensajes, que enruta el mensaje desde un conjunto de clientes o servidores a otros clientes o servidores. Un escenario o API diferente requiere una directiva de enrutamiento diferente.
Para eco, el cliente envía un mensaje a sí mismo y es él mismo el destino del enrutamiento. Este patrón tiene el menor costo de enrutamiento. Sin embargo, para difusión, enviar al grupo y enviar a conexión, Azure SignalR Service 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 el modo predeterminado, el servidor de aplicaciones también podría convertirse en un cuello de botella para determinados escenarios. El SDK de Azure SignalR tiene que invocar el centro y, al mismo tiempo, mantener una conexión dinámica con cada cliente mediante señales de latido.
En modo sin servidor, el cliente envía un mensaje mediante http post, que no es tan eficaz como WebSocket.
Protocolo
Otro factor es de protocolo: JSON y MessagePack. MessagePack es más pequeño y se entrega con más rapidez que JSON. Sin embargo, es posible que MessagePack no mejore el rendimiento. El rendimiento de Azure SignalR Service no es sensible a los protocolos porque no descodifica la carga del mensaje durante el reenvío de mensajes desde clientes a servidores o viceversa.
Encontrar una SKU adecuada
¿Cómo se puede evaluar la capacidad de entrada y salida o buscar el nivel adecuado para un caso de uso específico?
Supongamos que el servidor de aplicaciones es lo suficientemente eficaz y no es el cuello de botella de rendimiento. Luego, compruebe el ancho de banda entrante y saliente máximo para cada nivel.
Evaluación rápida
Para una evaluación rápida, supongamos la siguiente configuración predeterminada:
- El tipo de transporte es WebSocket.
- El tamaño del mensaje es de 2048 bytes.
- Se envía un mensaje cada segundo.
- Azure SignalR Service está en el modo predeterminado.
Cada nivel tiene su propio ancho de banda entrante y saliente máximo. No se garantiza una experiencia de usuario fluida después de que la conexión entrante o saliente supere el límite.
Eco ofrece el ancho de banda entrante máximo porque tiene el menor costo de enrutamiento. Difusión define el ancho de banda de mensaje saliente máximo.
No se deben superan los valores resaltados en las dos tablas siguientes.
| 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 |
| Ancho de banda entrante | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1000 MBps | 2000 MBps |
| Ancho de banda saliente | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1000 MBps | 2000 Mbps |
| Difusión | 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 |
| Ancho de banda entrante | 4 Kbps | 4 Kbps | 4 Kbps | 4 Kbps | 4 Kbps | 4 Kbps | 4 Kbps | 4 Kbps |
| Ancho de banda saliente | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2000 MBps | 4000 MBps |
Ancho de banda entrante y Ancho de banda saliente son el tamaño total de mensajes por segundo. Estas son las fórmulas para ellos:
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 tiempo de envío de un mensaje. Normalmente es 1 segundo por mensaje, lo que implica enviar 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 por mensaje significa enviar dos mensajes cada segundo.
Connections: el umbral máximo confirmado de Azure SignalR Service para cada nivel. Si el número de conexión aumenta aún más, sufre una limitación de conexión.
Nota:
Debe escalar verticalmente a la SKU Premium_P2 tener un tamaño de unidad superior a 100.
Evaluación para casos de uso complejos
Mayor tamaño de mensaje o velocidad de envío diferente
El caso de uso real es más complicado. Puede enviar un mensaje de más de 2048 bytes o la tasa de mensajes de envío no es un mensaje por segundo. Tomemos la difusión de unit 100 como ejemplo para encontrar cómo evaluar su rendimiento.
En la tabla siguiente se muestra un caso de uso real de difusión. Sin embargo, el tamaño de mensaje, número de conexiones y velocidad de envío de mensajes son diferentes de lo que se supone que en la sección anterior. La cuestión es cómo podemos deducir alguno de esos elementos (tamaño de mensaje, número de conexiones o velocidad de envío de mensaje) si conocemos solo dos de ellos.
| Difusión | Tamaño del mensaje | Mensajes entrantes simultáneos | Conexiones | Intervalos de envío |
|---|---|---|---|---|
| 1 | 20 KB | 1 | 100 000 | 5 segundos |
| 2 | 256 KB | 1 | 8,000 | 5 segundos |
La siguiente fórmula es fácil de deducir basándose en la fórmula anterior:
outboundConnections = outboundBandwidth * sendInterval / messageSize
Para la unidad 100, el ancho de banda de salida máximo es de 400 MB de la tabla anterior. Para un tamaño de mensaje de 20 KB, el número máximo de conexiones de salida debe ser 400 MB * 5 / 20 KB = 100 000, que coincide con el valor real.
Casos de uso mixtos
En el caso de uso real, se suele mezclar los cuatro casos de uso básicos: eco, difusión, enviar al grupo y enviar a conexión. La metodología que se usa para evaluar la capacidad es la siguiente:
- Dividir los casos de uso mixtos en cuatro casos de uso básicos.
- Calcular el ancho de banda máximo de mensajes entrantes y salientes con las fórmulas anteriores por separado.
- Sumar los cálculos de ancho de banda para obtener el total ancho de banda entrante y saliente máximo.
Luego, elegir el nivel adecuado de las tablas de ancho de banda entrante y saliente máximo.
Nota:
Para enviar un mensaje a cientos o miles de grupos pequeños o para miles de clientes que envían un mensaje entre sí, el costo de enrutamiento será un elemento dominante. Debe tener en cuenta este impacto.
Para el caso de uso de enviar un mensaje a los clientes, asegúrese de que el servidor de aplicaciones no sea el cuello de botella. En la siguiente sección "Caso práctico" se proporcionan directrices sobre cuántos servidores de aplicaciones se necesitan y cuántas conexiones de servidor se deben configurar.
Caso práctico
En las siguientes secciones se describen cuatro casos de uso típicos de transporte de WebSocket: eco, difusión, enviar al grupo y enviar a conexión. Para cada escenario, en la sección se muestra la capacidad actual de entrada y salida para Azure SignalR Service. También se explican los principales factores que afectan al rendimiento.
En el modo predeterminado, el servidor de aplicaciones crea cinco conexiones de servidor con Azure SignalR Service. El servidor de aplicaciones usa el SDK de Azure SignalR Service de forma predeterminada. En los siguientes resultados de pruebas de rendimiento, las conexiones de servidor se aumentan a 15 (o más para la difusión y el envío de un mensaje a un grupo de gran tamaño).
Casos de uso diferentes tienen requisitos diferentes para los servidores de aplicaciones. Difusión necesita un número pequeño de servidores de aplicaciones. Eco o enviar a conexión necesita varios servidores de aplicación.
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.
Modo predeterminado
En el modo predeterminado, participan clientes, servidores de aplicaciones web y Azure SignalR Service. Cada cliente significa una sola conexión.
Echo
En primer lugar, una aplicación web se conecta a Azure SignalR Service. En segundo lugar, muchos clientes se conectan a la aplicación web, que redirige los clientes a Azure SignalR Service con el token de acceso y el punto de conexión. Luego, los clientes establecen conexiones WebSocket con Azure SignalR Service.
Cuando todos los clientes establezcan conexiones, comienzan a enviar un mensaje que contiene una marca de tiempo al centro concreto cada segundo. El centro envía de vuelta un mensaje de eco a su cliente original. Cada cliente calcula la latencia cuando recibe el mensaje de eco de vuelta.
En el siguiente diagrama, 5 a 8 (tráfico resaltado en rojo) se encuentran en un bucle. El bucle se ejecuta durante un tiempo predeterminado (5 minutos) y obtiene la estadística de la latencia de todos los mensajes.
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 | 1,000 | 2.000 | 10 000 | 50.000 | 100 000 | 200 000 | 500.000 | 1 000 000 |
| Ancho de banda entrante y saliente | 2 MBps | 4 MBps | 20 MBps | 100 MBps | 200 MBps | 400 MBps | 1000 MBps | 2000 Mbps |
En este caso de uso, cada cliente invoca el centro definido en el servidor de aplicaciones. El centro simplemente llama al método definido en el cliente original. Este centro es el más ligero para eco.
public void Echo(IDictionary<string, object> data)
{
Clients.Client(Context.ConnectionId).SendAsync("RecordLatency", data);
}
Incluso para este centro sencillo, la presión del tráfico en el servidor de aplicaciones se destaca a medida que aumenta la carga de mensajes entrantes eco. Esta presión de tráfico requiere muchos servidores de aplicaciones para niveles de SKU de gran tamaño. En la tabla siguiente se muestra el número de servidores de aplicaciones para cada nivel.
| 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 |
| Número de servidores de aplicaciones | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Nota:
El número de conexiones de cliente, tamaño de mensaje, velocidad de envío de mensajes, nivel de SKU y CPU o memoria del servidor de aplicaciones afectan al rendimiento global de eco.
Difusión
Para difusión, cuando la aplicación web recibe el mensaje, lo difunde a todos los clientes. Cuantos más clientes haya que difundir, más tráfico de mensajes hay para todos los clientes. Consulte el diagrama siguiente:
Un número pequeño de clientes difunden. El ancho de banda de mensajes entrante es pequeño, pero el ancho de banda saliente es enorme. El ancho de banda de mensajes saliente aumenta a medida que aumenta la velocidad de conexión o difusión de cliente.
En la tabla siguiente se proporciona un resumen de las conexiones de cliente, número de mensajes entrantes y salientes, y ancho de banda máximos.
| Difusión | 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 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Mensajes salientes por segundo | 2\.000 | 4\.000 | 20.000 | 100 000 | 200 000 | 400.000 | 1 000 000 | 2 000 000 |
| Ancho de banda entrante | 4 Kbps | 4 Kbps | 4 Kbps | 4 Kbps | 4 Kbps | 4 Kbps | 4 Kbps | 4 Kbps |
| Ancho de banda saliente | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2000 Mbps | 4000 MBps |
Los clientes de difusión que publican mensajes son no más que cuatro. Necesitan menos servidores de aplicaciones en comparación con eco porque la cantidad de mensajes entrantes es pequeña. Dos servidores de aplicaciones son suficientes en cuanto al contrato de nivel de servicio y el rendimiento. Pero debe aumentar las conexiones de servidor predeterminadas para evitar el desequilibrio, especialmente para unidad superior a 50.
| Difusión | 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 servidores de aplicaciones | 1 | 1 | 1 | 2 | 2 | 4 | 10 | 20 |
Nota:
Aumente las conexiones de servidor predeterminadas de 5 a 40 en cada servidor de aplicaciones para evitar posibles conexiones de servidor desequilibradas a Azure SignalR Service.
El número de conexiones de cliente, tamaño de mensaje, velocidad de envío de mensajes y nivel de SKU afectan al rendimiento global para difusión.
Enviar al grupo
El caso de uso de enviar al grupo tiene un patrón de tráfico similar a difusión. La diferencia es que después de que los clientes establezcan conexiones WebSocket a Azure SignalR Service, deben unirse a grupos antes de poder enviar un mensaje a un grupo específico. En el diagrama siguiente se muestra este flujo de tráfico.
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 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.
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.
Enviar al grupo agrega un costo de enrutamiento a Azure SignalR Service 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 pequeño
El coste de enrutamiento es importante para enviar mensajes a muchos grupos pequeños. Actualmente, la implementación de Azure SignalR Service alcanza el límite de costos de enrutamiento en la unidad 50. 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 entrante, póngase en contacto con el soporte técnico.
| 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 |
Muchas de conexiones de cliente llaman al centro, por lo que el número de servidores aplicaciones también es fundamental para el rendimiento. En la tabla siguiente se enumeran los números de servidores de aplicaciones sugeridos.
| 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 servidores de aplicaciones | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Nota:
El número de conexiones de cliente, tamaño de mensaje, velocidad de envío de mensajes, coste de enrutamiento, nivel de SKU y CPU o memoria del servidor de aplicaciones afectan al rendimiento global de enviar a grupo pequeño.
El recuento de grupos, el recuento de miembros del grupo que se muestra en la tabla no son límites estrictos. Estos valores de parámetro se seleccionan para establecer un escenario de prueba comparativa estable. Por ejemplo, es correcto asignar cada conneciton a un grupo distinto. En esta configuración, el rendimiento está cerca de enviar a la conexión.
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 muestra el ancho de banda saliente máximo, que es prácticamente el mismo que para difusión.
| 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 | 500 | 1,000 | 2.000 | 5.000 | 10 000 | 20.000 |
| Número de grupos | 10 | 10 | 10 | 10 | 10 | 10 | 10 | 10 |
| Mensajes entrantes por segundo | 20 | 20 | 20 | 20 | 20 | 20 | 20 | 20 |
| Ancho de banda entrante | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps | 40 KBps |
| Mensajes salientes por segundo | 2\.000 | 4\.000 | 20.000 | 100 000 | 200 000 | 400.000 | 1 000 000 | 2 000 000 |
| Ancho de banda saliente | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2000 Mbps | 4000 MBps |
El número de conexiones de envío 40 como máximo. La carga en el servidor de aplicaciones es pequeña, por lo que el número de aplicaciones web sugerido es pequeño.
| 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 servidores de aplicaciones | 1 | 1 | 2 | 2 | 2 | 4 | 10 | 20 |
Nota:
Aumente las conexiones de servidor predeterminadas de 5 a 40 en cada servidor de aplicaciones para evitar posibles conexiones de servidor desequilibradas a Azure SignalR Service.
El número de conexiones de cliente, tamaño de mensaje, velocidad de envío de mensajes, coste de enrutamiento y nivel de SKU afectan al rendimiento global de enviar a grupo grande.
Enviar a conexión
En el caso de uso de enviar a conexión, cuando los clientes establecen las conexiones a Azure SignalR Service, cada cliente llama a un centro especial para obtener su propio identificador de conexión. El banco de pruebas de rendimiento recopila todos los identificadores de conexión, los pone en orden aleatorio y los reasigna a todos los clientes como un destino de envío. Los clientes siguen enviando el mensaje a la conexión de destino hasta que finalice la prueba de rendimiento.
El coste de enrutamiento para enviar a conexión es similar al coste de enviar a grupo pequeño.
A medida que aumenta el número de conexiones, el costo de enrutamiento se convierte en un factor crítico que limita el rendimiento general. En particular, la unidad 20 marca el umbral donde el servicio alcanza el cuello de botella de enrutamiento. Los aumentos adicionales en el recuento de unidades no producen mejoras de rendimiento a menos que haya un cambio a Premium_P2(unidad >=100), lo que mejora las funcionalidades de enrutamiento.
En la tabla siguiente se proporciona un resumen estadístico después de varias etapas de ejecución del banco de pruebas enviar a conexión.
| Enviar a conexión | Unidad 1 | Unidad 2 | Unidad 20 | Unidad 50 | Unidad 100 | Unidad 200 | Unidad 500 | Unidad 1000 |
|---|---|---|---|---|---|---|---|---|
| Conexiones | 1,000 | 2.000 | 20.000 | 50.000 | 100 000 | 200 000 | 500.000 | 1 000 000 |
| Mensajes entrantes y salientes por segundo | 1,000 | 2.000 | 20.000 | 20.000 | 20.000 | 40.000 | 100 000 | 200 000 |
| Ancho de banda entrante y saliente | 2 MBps | 4 MBps | 40 MBps | 40 MBps | 40 MBps | 80 MBps | 200 MBps | 400 MBps |
Nota:
A pesar del estancamiento de los mensajes entrantes o salientes por segundo después de la unidad 20, la capacidad de más conexiones sigue creciendo. En escenarios empresariales reales, a menudo es el recuento de conexiones, no su actividad simultánea de envío de mensajes, que forma el cuello de botella. Es poco habitual que todas las conexiones envíen mensajes activamente a frecuencias tan altas como lo hace la prueba comparativa.
En este caso de uso se requiere una carga elevada en el servidor de aplicaciones. Consulta en la tabla siguiente el número de servidores de aplicaciones sugerido.
| Enviar a conexión | 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 servidores de aplicaciones | 1 | 1 | 1 | 5 | 10 | 20 | 50 | 100 |
Nota:
El número de conexiones de cliente, tamaño de mensaje, velocidad de envío de mensajes, coste de enrutamiento, nivel de SKU y CPU o memoria del servidor de aplicaciones afectan al rendimiento global de enviar a conexión.
ASP.NET SignalR
Azure SignalR Service proporciona la misma capacidad de rendimiento para ASP.NET SignalR.
Modo sin servidor
Los clientes y Azure SignalR Service participan en el modo sin servidor. Cada cliente significa una sola conexión. El cliente envía mensajes a través de la API de REST a otro cliente o mensajes de difusión a todos.
El envío de mensajes de alta densidad a través de la API REST no es tan eficaz como el uso de WebSocket. Requiere la creación de una nueva conexión HTTP cada vez y eso implica un coste adicional en modo sin servidor.
Difusión a través de la API de REST
Todos los clientes establecen conexiones WebSocket con Azure SignalR Service. Luego, algunos clientes comienzan a difundir a través de la API de REST. El envío de mensajes (entrantes) es todo a través de HTTP Post, que no es eficaz en comparación con WebSocket.
| 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 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
| Mensajes salientes por segundo | 2\.000 | 4\.000 | 20.000 | 100 000 | 200 000 | 400.000 | 1 000 000 | 2 000 000 |
| Ancho de banda entrante | 4 Kbps | 4 Kbps | 4 Kbps | 4 Kbps | 4 Kbps | 4 Kbps | 4 Kbps | 4 Kbps |
| Ancho de banda saliente | 4 MBps | 8 MBps | 40 MBps | 200 MBps | 400 MBps | 800 MBps | 2000 MBps | 4000 MBps |
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 a Azure SignalR Service. Después de que los clientes establezcan conexiones de WebSocket con Azure SignalR Service, comienzan a enviar mensajes a otros usuarios a través de HTTP Post.
| 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 o salientes por segundo | 200 | 400 | 2 000 | 10 000 | 20.000 | 40.000 | 100 000 | 200 000 |
| Ancho de banda entrante o saliente | 400 Kbps | 800 Kbps | 4 MBps | 20 MBps | 40 MBps | 80 MBps | 200 MBps | 400 MBps |
Entornos de prueba de rendimiento
Para todos los casos de uso enumerados anteriormente, realizamos las pruebas de rendimiento en un entorno de Azure. Como máximo, usamos 200 máquinas virtuales cliente y 100 máquinas virtuales del servidor de aplicaciones. Estos son algunos detalles:
Tamaño de máquina virtual de cliente: StandardDS2V2 (2 vCPU, 7G de memoria)
Tamaño de máquina virtual del servidor de aplicaciones: StandardF4sV2 (4 vCPU, 8G Memory)
Conexiones de servidor de Azure SDK de SignalR: 15
Herramientas de rendimiento
Puede encontrar herramientas de rendimiento para Azure SignalR Service en GitHub.
Pasos siguientes
En este artículo, se obtuvo introducción al rendimiento de Azure SignalR Service en escenarios de caso de uso típicos.
Para obtener detalles sobre los aspectos internos del servicio y el escalado, consulte las siguientes guías: