Node.js, Socket.io, Redis pub / sub high volumen, dificultades de baja latencia

Cuando se combinan socket.io/node.js y redis pub / sub en un intento de crear un sistema de transmisión web en tiempo real impulsado por eventos del servidor que puedan manejar múltiples transportes, parece haber tres enfoques:

'createClient' es una conexión redis y se suscribe a canal (es). En la conexión del cliente socket.io, únase al cliente en una sala socket.io. En el evento redis.on ("mensaje", ...), llame a io.sockets.in (sala) .emit ("evento", datos) para distribuir a todos los clientes en la sala correspondiente. Me gusta¿Cómo reutilizar la conexión redis en socket.io?

'createClient' una conexión redis. En la conexión del cliente socket.io, únase al cliente en una sala socket.io y suscríbase a los canales redis relevantes. Incluya redis.on ("mensaje", ...) dentro del cierre de la conexión del cliente y al recibir el mensaje, llame a client.emit ("evento", datos) para provocar el evento en el cliente específico. Como la respuesta enEjemplos en el uso de RedisStore en socket.io

Utilice la RedisStore integrada en socket.io y la 'transmisión' desde el único canal de "envío" en Redis siguiendo el protocolo de especificación de socketio.

El número 1 permite el manejo del evento Redis sub y asociado una vez para todos los clientes. El número 2 ofrece un gancho más directo en el pub / sub Redis. El número 3 es más simple, pero ofrece poco control sobre los eventos de mensajería.

Sin embargo, en mis pruebas, todas muestran un rendimiento inesperadamente bajo con más de 1 cliente conectado. Los eventos del servidor en cuestión son 1.000 mensajes publicados en un canal redis lo más rápido posible, para ser distribuidos lo más rápido posible. El rendimiento se mide por los tiempos en los clientes conectados (basado en socket.io-client que registra las marcas de tiempo en una lista de Redis para su análisis).

Lo que supongo es que en la opción 1, el servidor recibe el mensaje, luego lo escribe secuencialmente a todos los clientes conectados. En la opción 2, el servidor recibe cada mensaje varias veces (una vez por suscripción de cliente) y lo escribe en el cliente correspondiente. En cualquier caso, el servidor no recibe el segundo evento de mensaje hasta que se comunica a todos los clientes conectados. Una situación claramente exacerbada con la creciente concurrencia.

Esto parece en desacuerdo con la sabiduría percibida de las capacidades de las pilas. Quiero creer, pero estoy luchando.

¿Este escenario (distribución de baja latencia de gran volumen de mensajes) no es una opción con estas herramientas (todavía?), O me falta un truco?

Respuestas a la pregunta(1)

Su respuesta a la pregunta