html5 - description - Costos de eventos enviados por el servidor en el lado del servidor

title html attribute

Question

Si entiendo correctamente el principio de Eventos enviados por el servidor, cada vez que un cliente se registra en un EventSource, en realidad abre una nueva conexión HTTP al recurso que administra el evento. Al contrario de otras solicitudes HTTP, la conexión permanece activa, por lo que el proceso / subproceso del servidor dedicado a este cliente continúa ejecutándose hasta que el cliente se desconecta.

¿Qué pasa si tenemos 1000 clientes conectados a una aplicación utilizando SSE? ¿Tendríamos 1000 procesos / subprocesos (haciendo lo mismo) ejecutándose simultáneamente para manejar los SSE? Supongo que estoy equivocado, pero si no lo estoy, ¿es realmente más eficiente que el método de sondeo AJAX habitual, donde al menos el servidor no necesita ejecutar tantos procesos / subprocesos simultáneamente?

Answer 1

Depende del modelo de subprocesos del servidor. Apache defecto, Apache es un subproceso (o proceso) por conexión, por lo que, incluso si los subprocesos no están haciendo mucho (como se espera con las conexiones SSE), se quedan allí usando recursos.

Los servidores como Nginx tienen un modelo ligeramente diferente, cada hilo maneja múltiples solicitudes de forma asíncrona. Así que cosas como SSE y WebSockets son mucho más eficientes.

Se puede hacer que Apache se desempeñe más como Nginx y servidores similares.

Answer 2

Sí, cada cliente mantiene la conexión abierta mientras pueda. Con 1000 usuarios simultáneos, tendrías 1000 conexiones TCP / IP abiertas.

Sin embargo, si cada conexión utiliza un hilo depende del servidor.

Apache normalmente mantiene un hilo en ejecución para cada conexión, por lo que es bastante caro. Con Apache es mejor deshabilitar KeepAlive y usar el sondeo.

OTOH con servidores basados ​​en eventos como node.js, puede tener un solo proceso que administra todas las conexiones, por lo que el costo de cada conexión es mucho menor y debería poder mantener abiertas miles de conexiones.

Lo bueno de SSE es que también puede usarlo para hacer encuestas. Tiene una directiva retry: que especifica cuánto tiempo debe esperar el cliente antes de volver a conectarse (sondeo) nuevamente. Simplemente envíe eso y cierre la conexión cuando desee realizar un sondeo.