¿Qué requiere más recursos del servidor? Web-zócalos o cometa (sondeo largo)

Cada método tiene esencialmente el mismo costo, al menos en su nivel básico de comunicación: el zócalo. El costo es en la práctica mayor para una configuración de larga duración, y explicaré por qué.


Inicialmente se establece un zócalo para la comunicación. En horas extras, la “conexión de socket web” permanece abierta. Este es un recurso de socket único para todos los clientes, por lo que el socket puede enviar / recibir bytes. Sin embargo, la configuración de longpolling tiene un socket para cada cliente. Mantiene este socket abierto durante un tiempo, enviando mensajes periódicamente a medida que hay nuevo contenido disponible. cuando el socket está cerrado, el cliente debe detectar esto y reiniciar una nueva conexión. Al ignorar las situaciones en las que una conexión de websocket se rompe y debe restablecerse, el modelo de websocket es más eficiente, debido al costo inherente en el establecimiento de la conexión de socket entre el servidor y el cliente. En el mundo real, utilizando sockets persistentes, un trabajo de larga duración puede ofrecer una eficiencia similar a un trabajo de websocket, sin embargo, todo se reduce a la implementación del servidor.


Si estuvieras votando con PHP sería muy poco eficiente y probablemente consumirías todos tus recursos con muy pocos usuarios. Sin embargo, si tiene una larga apuesta con Java, es probable que pueda servir a muchos usuarios con una pila bastante modesta.


En resumen, es una buena pregunta, y teóricamente, , los websockets son más eficientes , sin embargo, en la práctica, hay demasiadas variables en juego para proclamar que cualquiera de los métodos usaría los recursos de manera más eficiente, teniendo en cuenta la distinción que los websockets necesitarán construir, en promedio menos sockets para la comunicación entre el servidor en el cliente, pero debido a la variable de la frecuencia con la que un cliente se desconectará / volverá a conectar al servidor websocket, no podemos decir que este sea el caso de manera concluyente, siempre. de hecho, encontrará lo opuesto para ser cierto, que el longpolling puede ser más eficiente y más confiable.


En caso de duda, use una implementación como socketio. Puedes apoyar a más clientes de esta manera.

No hay comparación entre los sondeos largos (es decir, las técnicas HTTP “Comet”) y WebSocket. WebSocket es full-duplex, es decir, transferencia de datos ascendente / descendente simultánea. Las técnicas de cometa son semidúplex, es decir, se envían en una dirección a la vez. Necesita 2 conexiones HTTP para la funcionalidad bidireccional con comunicación estilo Comet; y necesita administrar estas dos conexiones (es decir, manejar desconexiones, áreas móviles de bajo ancho de banda, etc.).

Si envía datos con frecuencia, esto requiere una frecuencia de sondeo corta. Cuanto más corta sea la frecuencia de sondeo, más recursos informáticos necesitará. Si sus datos no cambian, siempre está sondeando. Y si los datos son críticos, estará “en la oscuridad” si sus datos cambian entre sus períodos de votación, es decir, su aplicación necesita esperar el período de votación para activar una actualización. Puede hacer que el período de sondeo sea muy, muy corto, pero luego su máquina estará ocupada sondeando y realmente no realizará un trabajo efectivo. Puede hacer que el período de votación sea largo, pero luego puede perder datos importantes.

Si tiene que escalar a miles de conexiones (o cientos de miles), esto se amplía por órdenes de magnitud.

El sondeo largo es una técnica antigua. En una era de redes rápidas y WebSocket, debe evitarse siempre que sea posible. A veces, el sondeo largo se utiliza para la conectividad “en vivo” cuando WebSocket no puede atravesar algún intermediario de red. En ese caso, se conectará, pero su rendimiento se verá muy afectado.