Estamos implementando un servicio que es utilizado por muchos usuarios al mismo tiempo. En picos podemos tener decenas de miles de personas en línea.
Una parte crítica de nuestro servicio necesita una reimplementación, por lo que tratamos de pensar en nuevas formas de hacerlo. En este momento, enviamos una solicitud HTTP AJAX simple y muy corta/pequeña basada en la interacción del usuario:
Al mismo tiempo, en algún caso (1 de cada 10) tenemos abierto EventSource del que leemos algunas modificaciones en el servidor.
La pregunta es si este modelo es lo suficientemente bueno o si es mejor abrir un WebSocket y pasar todo a través de WebSockets.
¿Cuál debe ser la decisión para la correcta implementación?
Se observó que esta pregunta responde de la misma manera: protocolo WebSockets frente a HTTP ; sin embargo, solicito un caso de uso específico. La pregunta relacionada se hace más bien en general.
- Desventaja: cuando hay mucha gente en línea, mantendríamos miles de conexiones activas
Puede implementar su servicio para cerrar la conexión websocket inactiva después de un tiempo de espera. Probablemente sea así como funciona EventSource para usted, por lo que no mantiene demasiadas conexiones activas. (Características de rendimiento similares.)
(Pero si confía en la reconexión automática de EventSource proporcionada por el navegador, entonces cambiar a WebSocket significa que necesita escribir más código para la lógica de la reconexión).
Por lo general, WebSocket debería tener menos sobrecarga de tráfico de red. Pero la diferencia depende de cómo se implemente su servicio actual. Si ya ha optimizado su lógica y exprimido cada bit de rendimiento con AJAX y EventSource , el uso de WebSocket podría ser una mejora marginal.