Escalabilidad del servidor - HTML 5 websockets vs Comet

Question

Muchas implementaciones de Comet como Caplin proporcionan soluciones escalables para el servidor.

siguiente es uno de las estadísticas de Caplin sitio:

una sola instancia de Caplin liberador puede soportar hasta 100.000 clientes que reciben cada uno 1 de mensajes por segundo con una latencia media de menos de 7 ms.

¿Cómo se puede comparar esto con websockets HTML5 en cualquier servidor web? ¿Alguien puede indicarme alguna estadística de websockets de HTML 5?

Answer 1

Es difícil saber cómo se compara con algo porque no sabemos cuán grande es el tamaño de la carga útil (promedio). Debajo del capó (como en la forma en que se implementa el servidor), la transmisión HTTP y los websockets son prácticamente idénticos, aparte del saludo inicial, que es más complicado cuando se hace con HTTP obviamente.

Si escribiste tu propio servidor de websocket en C (ala Caplin), probablemente podrías alcanzar esos números sin demasiada dificultad. La mayoría de las implementaciones de websocket se realizan a través de paquetes de servidores existentes (como Jetty), por lo que la comparación no sería justa.

Algunos puntos de referencia:
http://webtide.intalio.com/2011/09/cometd-2-4-0-websocket-benchmarks/
http://webtide.intalio.com/2011/08/prelim-cometd-websocket-benchmarks/

Sin embargo, si nos fijamos en eventos C puntos de referencia lib, como libev y libevent, los números se ven significativamente más atractivo:
http://libev.schmorp.de/bench.html

Answer 2

En teoría WebSockets puede escalar mucho mejor que HTTP, pero hay algunas advertencias y algunas formas de abordar esas advertencias también.

La complejidad del procesamiento del encabezado de saludo de HTTP frente a WebSockets es casi la misma. El protocolo de enlace HTTP (e inicial de WebSocket) puede superar fácilmente 1K de datos (debido a cookies, etc.). La diferencia importante es que el protocolo de enlace HTTP ocurre nuevamente cada mensaje. Una vez que se establece una conexión WebSocket, la sobrecarga por mensaje es de solo 2-14 bytes.

Las excelentes conexiones embarcadero de referencia publicados en la respuesta de @ David Titarenco (1, 2) muestran que WebSockets pueden alcanzar fácilmente más de un orden de magnitud mejor latencia si se compara con el cometa.

Consulte this answer para obtener más información sobre la ampliación de WebSockets frente a HTTP.

Advertencias:

• conexiones WebSocket son de larga vida a diferencia de las conexiones HTTP que son de corta duración. Esto reduce significativamente la sobrecarga (sin creación y administración de socket para cada solicitud/respuesta), pero sí significa que para escalar un servidor por encima de 64k hosts de cliente simultáneos, necesitará usar trucos como múltiples direcciones IP en el mismo servidor.

• Debido a problemas de seguridad con los intermediarios web, los mensajes WebSocket de navegador a servidor tienen enmascarados todos los datos de la carga útil XOR. Esto agrega cierta utilización de CPU al servidor para decodificar los mensajes.Sin embargo, XOR es una de las operaciones más eficientes en la mayoría de las arquitecturas de CPU y, a menudo, hay asistencia de hardware disponible. Los mensajes de servidor a navegador no están enmascarados y dado que muchos usos de WebSockets no requieren grandes cantidades de datos enviados desde el navegador al servidor, este no es un gran problema.

Answer 3

Divulgación - Yo trabajo para Caplin.

Hay un poco de información errónea en esta página así que me gustaría tratar de hacerlo más claro ..

creo que podríamos dividir los métodos de los que estamos hablando en tres campos ..

1. Comet HTTP de votación - incluyendo sondeo largo
2. Comet transmisión HTTP - servidor para los mensajes del cliente utilizar un único socket constante sin sobrecarga de cabecera HTTP después de la configuración inicial
3. Comet WebSocket - solo socket bidireccional

Los veo a todos como Comet, ya que Comet es solo un paradigma, pero desde que salió WebSocket algunas personas quieren tratarlo como si fuera diferente o reemplaza a Comet, pero es solo otra técnica, y a menos que sea contentos solo de soportar los últimos navegadores, entonces no puedes simplemente confiar en WebSocket.

En lo que a rendimiento se refiere, la mayoría de los puntos de referencia se concentran en el servidor de mensajes del cliente - número de usuarios, número de mensajes por segundo, y la latencia de los mensajes. Para este escenario, no existe una diferencia fundamental entre HTTP Streaming y WebSocket: ambos escriben mensajes en un socket abierto con poco o ningún encabezado o sobrecarga.

sondeo largo puede dar buena latencia si la frecuencia de los mensajes es baja. Sin embargo, si tiene dos mensajes (servidor a cliente) en rápida sucesión, el segundo no llegará al cliente hasta que se realice una nueva solicitud después de que se reciba el primer mensaje.

Creo que alguien tocó en HTTP KeepAlive. Obviamente, esto puede mejorar el sondeo largo: aún tiene la sobrecarga de la ida y vuelta y los encabezados, pero no siempre la creación del socket.

Dónde WebSocket debe mejorar Streaming HTTP en escenarios en los que hay más en el cliente a los mensajes del servidor. Relacionar estos escenarios con el mundo real crea configuraciones un poco más arbitrarias, en comparación con la simple comprensión de "enviar muchos mensajes a muchos clientes" que todos puedan entender. Por ejemplo, en una aplicación de comercio, la creación de un escenario en el que se incluyen los usuarios que ejecutan las operaciones (es decir, el cliente de mensajes del servidor) es fácil, pero los resultados de un poco menos significativo que el servidor de base de escenarios de cliente. Los operadores no están tratando de hacer 100 operaciones/seg. Por lo que se obtienen resultados como "10000 usuarios que reciben 100 mensajes/seg mientras también envían un mensaje al cliente una vez cada 5 minutos". La parte más interesante para el mensaje del cliente al servidor es la latencia, ya que la cantidad de mensajes requeridos generalmente es insignificante en comparación con los mensajes del servidor al cliente.

Otro punto que alguien ha mencionado anteriormente, alrededor de 64k clientes, No necesita hacer nada inteligente para admitir más de 64k sockets en un servidor, aparte de configurar los descriptores de los archivos de número, etc. Si estaba intentando hacer una conexión de 64k desde una máquina de cliente único, que es totalmente diferente, ya que necesitan un número de puerto para cada uno; en el extremo del servidor está bien, es el extremo de escucha, y puede ir por encima de los sockets de 64 k.

Answer 4

Haciendo caso omiso de cualquier forma de sondeo, lo que, como se explica en otro lugar, puede introducir latencia cuando la velocidad de actualización es alta, las tres técnicas más habituales de este lenguaje en streaming son:

1. WebSocket
2. Comet XHR/XDR en streaming
3. Comet siempre IFrame

WebSocket es de lejos la solución más limpia, pero no hay todavía problemas en términos de infraestructura de red y el navegador apoyándolo. Cuanto antes se pueda confiar en el mejor.

XHR/XDR & Forever IFrame son buenos para enviar datos a los clientes desde el servidor, pero requieren varios hacks para que funcionen de forma coherente en todos los navegadores. En mi experiencia, estos enfoques de Comet son siempre un poco más lentos que WebSockets porque hay mucho más código de JavaScript del lado del cliente requerido para hacerlo funcionar, desde la perspectiva del servidor, sin embargo, el envío de datos a través del cable ocurre a la misma velocidad.

Éstos son algunos más WebSocket benchmark graphs, esta vez para nuestro producto my-Channels Nirvana.

Saltar más allá de los gráficos de datos de multidifusión y binarios hasta el último gráfico de la página (JavaScript Alta Velocidad de actualización)

En resumen - Los resultados muestran Nirvana WebSocket la entrega de 50 eventos/seg a 2.500K usuarios con 800 microsegundos estado latente. Con 5.000 usuarios (un total de 250k eventos/segundo transmitidos), la latencia es de 2 milisegundos.