Benchmark de REST vs WebSocket
AbrahamWebSocket Es una forma de comunicación con el servidor mucho más potente que el tradicional REST. Entre las cosas que permite que no son posibles directamente con REST están la comunicación bidireccional entre el cliente y el servidor, o el hecho de que el servidor y el cliente pueden comunicarse el uno con el otro enviando datos de modo simultáneo.
Esto suele ser bastante bien conocido. Pero además, el uso de WebSocket riene consecuencias bastante considerables a nivel de tiempo de respuesta del servidor de aplicaciones. Arun Gupta ha hecho una serie de pruebas empleando WildFly 8 y estas pruebas muestran que el rendimiento de WebSocket es muy superior al de REST por el hecho de que para emplear REST es necesario crear una conexión TCP/IP por cada petición. Este gráfico muestra el tiempo que le lleva al servidor de aplicaciones responder un número determinado de mensajes a través de una peticiones realizadas por WebSocket y por REST:
En el post original Arun tiene otras pruebas de rendimiento diferentes, pero en general los resultados son similares a esta prueba; WebSocket permite responder las peticiones en mucho menos tiempo. Lo que no han medido las pruebas de Arun es el impacto que tiene el hecho de mantener continuamente abiertas las conexiones con el servidor en los recursos consumidos en el servidor, o a la hora de escalar la aplicación.
¿Qué os parece este benchmark?
Reader Comments (10)
¿Y algún lector de Javahispano tiene experiencia con Websocket en sitios grandes para decirnos que pasa con los servidores al mantener tantas conexiones abiertas? Es que tengo bastante curiosidad con el tema...
nilojg: según dice el artículo original lo que hace es crear una única conexión TCP/IP para todas las comunicaciones.
Single TCP Connection: Typically a new TCP connection is initiated for a HTTP request and terminated after the response is received. A new TCP connection need to be established for another HTTP request/response. For WebSocket, the HTTP connection is upgraded using standard HTTP Upgrade mechanism and client and server communicate over that same TCP connection for the lifecycle of WebSocket connection.
Pregunta desde el desconocimiento absoluto. ¿WebSocket tiene algo como JAX-RS o es mas bien como una conexión especial a un 'servlet'?
Buenas,
Websocket mantiene una conexion constantemente abierta con el servidor por lo que permite hacer notificaciones push desde el servidor en tiempor real.
Anteriormente esto solo se podia hacer con tecnicas comet utilizando algoritmos como el long polling y similares que solian dejar fritos tanto al cliente como al servidor con bastante facilidad.
En cuanto al articulo, de tan absurdo que es, no merece comentario alguno.
Un saludo
Es un socket sobre tcp al que el browser se conecta y va pidiendo info(http://tools.ietf.org/html/rfc6455) es decir comunicación bidireccional. Ya hize varios principalmente para barras de progreso, tenemos un proceso donde hay que generar como 4mil xml e ir introduciendo cambios, calculos, enviar a un webservice de un tercero y no le va mal. Pero la verdad no se que pase si se usa en exceso, por decir al intentar hacer una app RIA, desconozco si surjan otros problemas(que en parte tendran que atenderse con javascript).
Anónimo, sí, si eso lo entiendo. Lo que me pregunto es si en un Facebook o un ElPais, que tienen miles de usuarios concurrentes les dejara fritos los servidores tener miles de sockets abiertos mientras el usuario este dentro pasando el rato.
Ahora alguien pincha en un link y se abren una docena de conexiones para él solito para bajar el artículo, las imagenes, etc, de forma concurrente, pero después se cierran durante un rato para que las use otro cliente mientras el usuario lee el artículo. Cada usuario abre más conexiones pero durante un periodo corto, así que digamos que lo que importa es saber cuantos usuarios tienes al mismo tiempo durante un par de segundos para dimensionar el servidor.
Por lo que entiendo, con websocket se abre solo una, lo que es mejor, pero se mantiene abierta mientras el usuario está ahí colgado, por lo que par dimensionar el servidor tienes que saber cuantos usuarios tienes a lo largo de la mañana.
Es decir, que sin tener ni pajotera idea de como funciona en el mundo real, lo veo para intranets donde sabes cuantos clientes vas a tener, pero no para soltarlo a internet, donde puedes morir de éxito, pero ya digo que no se como funciona, y por eso preguntaba, por si alguien lo había usado en el mundo real.
Guenas.
Me pregunto para que reinventar la rueda con los websockets. Hacen exactamente lo mismo que los sockets TCP planos pero añadiendo una capa mas, mas pobre y pesado
La conexión HTTP estándar aun tiene el pase de que es efímera y por tanto mas escalable pero si se va a mantener la conexión abierta porque limitar los mas de 65000 puertos disponibles.
Estoy harto de oir la excusa de los firewalls. Si se puede abrir el puerto 80 cuesta el mismo trabajo abrir el puerto N. Que se lo curren un poco los de sistemas, que abrir un puerto tampoco es un trauma.
Un saludo
Entiendo que el benchmark se ha hecho sin usar la opción keep-alive en el servidor, para que el socket se mantenga abierto. En ese caso los resultados no serían tan escandalosos. La opción del websocket es interesante cuando la comunicación es bidireccional, es decir no solo hay petición/respuesta, sino también actualizaciones o pushing de datos desde el servidor al cliente, por ejemplo en temas de resultados deportivos. Lo bueno de los websockets es que ahora está disponible para todos, antes la única forma que conocía de hacer eso de forma fiable era con Adoble Livecycle Data Services, usando un cliente Flash/Flex. En cualquier caso, si solo se trata de petición/respuesta no tengo tan claro que suponga ninguna mejora con respecto al keep-alive, pero como siempre, esto no deja de ser una opinión...
Abrir un puerto no es un trauma, pero desde el punto de vista de seguridad hay que tenerlo en cuenta, y un administrador no va a estar dispuesto a abrir puertos "a lo loco".
Estoy de acuerdo con Jose Miguel, actualizaciones desde el servidor es conveniente WebSockets, pero sino, no lo veo tan claro...
Ya va tarde el comentario, pero para los futuros, les comento de forma escuálida cómo funcionan los sockets (pues yo he programado un server C a bajo nivel).
En realidad, son lo mismo que el REST, de hecho, toda petición REST que se le hace a un servidor se conecta a un socket, pasa la información según el protocolo (en caso de http, texto plano con cabeceras), se procesa en el servidor y se da respuesta mediante ese mismo socket, y se cierra o mejor dicho se desconecta inmediatamente (aun siendo “keep-alive”, esto depende más del servidor, pero básicamente es igual en todos). Entonces con REST, se conectan y desconectan sockets por cada petición que se hace al servidor, es decir, se pide una imagen, se conecta el socket, se pasa la imagen y se desconecta el socket.
La diferencia del REST y los websocket es que, en una primera instancia, el navegador manda una petición REST cualquiera para lo que se conoce como el apretón de manos o “handshake”, el cual si el servidor reconoce (y si ya cuenta con un algoritmo para codificación y decodificación de mensajes sockets HTML5), responde con un hash para indicarle al navegador, que ese socket (de tipo REST, bueno el que se conectó con una petición REST), permanecerá abierto hasta que cualquiera de los dos termine la conexión.
Porque son mejores los websokets? Porque, por ejemplo: mientras que con REST se conectan y desconectan 10000 sockets para realizar 1000 procesos para 1000 usuarios, con websocket se conectan 1000 sockets para realizar 1000 procesos para 1000 usuarios.
Es decir, websocket ahorra datos (se transmiten menos datos para una misma petición REST), ahorra tareas (menos conexiones y desconexiones), y velocidad de proceso.