Herramientas de pruebas de carga WebSocket: seis opciones

Entre las herramientas de pruebas de carga WebSocket, k6, Artillery, Gatling y Tsung soportan el protocolo de serie, mientras que JMeter necesita el plugin WebSocket Samplers y Locust, código cliente que escribas tú o su usuario experimental de Socket.IO. Elige según el lenguaje en el que escribe tu equipo y, después, según lo estrictamente que debas comprobar los mensajes que devuelve el servidor.

Para este artículo no hemos ejecutado estas herramientas contra un servidor WebSocket. Los datos salen de la documentación y el repositorio de cada proyecto, comprobados el 9 de octubre de 2026, y las notas de «Opta por» son nuestra opinión.

¿En qué se diferencia la carga WebSocket de la carga HTTP?

Un usuario WebSocket abre una conexión y la mantiene durante toda la sesión, y el servidor puede enviar mensajes cuando quiera. Por eso una prueba tiene dos palancas, las conexiones abiertas y los mensajes por segundo, y cada una carga el servidor a su manera.

La guía de WebSocket de k6 describe tráfico full-duplex sobre una sola conexión TCP y explica que un usuario virtual deja de repetir la función principal y ejecuta un bucle de eventos mientras el socket sigue abierto. La referencia de WebSocket de Gatling añade que el tráfico va en los dos sentidos, así que el modelo de petición y respuesta de HTTP ya no encaja.

Planifica tres tipos de prueba. Muchas conexiones inactivas muestran cuántos sockets pueden mantener tus servidores. Un grupo menor de clientes que hablan mucho pone a prueba el manejo de mensajes. Una difusión, en la que un mensaje llega a todos los suscriptores, pone a prueba el envío de mensajes push.

¿Qué deberías medir en una prueba de carga WebSocket?

Mide el tiempo de conexión, la latencia de los mensajes y las conexiones caídas, además de cuántas conexiones siguen abiertas. Son los valores que notan los usuarios de una aplicación en tiempo real.

Las métricas integradas de k6 incluyen ws_connecting, ws_ping, ws_session_duration, ws_sessions y contadores de mensajes. Ninguna cronometra un mensaje de la aplicación, así que el tiempo entre el mensaje de un cliente y la respuesta del servidor necesita una métrica Trend propia. El motor ws de Artillery informa del número y el ritmo de mensajes, y su motor de Socket.IO añade socketio.response_time, desde que se emite un mensaje hasta que llega la respuesta.

Para las conexiones caídas, cuenta los eventos close y error que tu script no haya provocado, y compara las sesiones iniciadas con las que siguen abiertas al final de cada etapa.

¿Cuándo es k6 la herramienta WebSocket adecuada?

Cuando tu equipo escribe JavaScript y cada usuario virtual debe mantener varios sockets a la vez. k6 trae soporte de WebSocket de serie, sin extensiones que instalar.

El módulo k6/websockets sigue la API WebSocket del navegador y usa un bucle de eventos global, que permite a un usuario virtual mantener varias conexiones abiertas. El módulo antiguo k6/ws sigue documentado, pero k6 recomienda k6/websockets para pruebas nuevas, y k6/experimental/websockets está obsoleto.

import { WebSocket } from 'k6/websockets';

export default function () {
  const ws = new WebSocket('wss://example.com/ws');
  ws.onopen = () => ws.send('hello');
  ws.onmessage = (e) => {
    console.log(e.data);
    ws.close();
  };
}

Los thresholds también funcionan con métricas propias, así que un objetivo de latencia incumplido le da a la CI un código de salida distinto de cero. Opta por Artillery cuando tu servidor hable Socket.IO y quieras comprobar emisiones y acuses de recibo sin escribir código cliente. Nuestra comparativa k6 vs Artillery cubre el resto de diferencias.

¿Cuándo encaja Artillery?

Cuando quieres escenarios YAML cortos, o cuando tu servidor usa Socket.IO. Los dos motores vienen con el propio Artillery.

Un escenario con el motor de WebSocket se construye con cinco acciones: connect, send, think, loop y function. El motor de Socket.IO va más allá: un emit puede declarar la respuesta que espera, validar un acuse de recibo con una coincidencia JSONPath y compartir escenario con peticiones HTTP, algo útil para aplicaciones que inician sesión por HTTP antes de abrir un socket.

Opta por k6 o Gatling cuando una prueba deba comprobar lo que devuelve un servidor WebSocket puro, porque la documentación del motor ws no describe ningún paso que espere o compare una respuesta.

¿Para quién es Gatling en WebSockets?

Para equipos en la JVM, o en el SDK de JavaScript de Gatling, que quieren escribir las comprobaciones de mensajes dentro del escenario. El soporte de WebSocket forma parte del SDK de HTTP de Gatling, así que los pasos HTTP y WebSocket comparten una misma simulación.

La referencia cubre connect, sendText, sendBytes y close, además de checks que bloquean hasta que llega el mensaje esperado o vence un tiempo límite. Los ajustes del protocolo permiten reconectar un socket que cerró el servidor, responder automáticamente a ciertos mensajes de texto como un ping y guardar en un búfer los mensajes que ningún check reconoció. Según su repositorio, WebSocket forma parte de la Community Edition con licencia Apache 2.0, sin límites.

Opta por k6 si prefieres reaccionar a los mensajes que empuja el servidor con manejadores de eventos en lugar de checks bloqueantes.

¿Puede JMeter hacer pruebas de carga de WebSockets?

Sí, con un plugin. JMeter no tiene sampler de WebSocket, y la extensión habitual es WebSocket Samplers de Peter Doornbosch.

La referencia de componentes de JMeter no menciona WebSocket en ningún momento. El repositorio del plugin describe seis samplers: abrir conexión, request-response, ping-pong, lectura única, escritura única y cierre. Se ejecutan en el propio hilo del Thread Group, soportan wss y tramas binarias, y pueden filtrar las tramas que no interesan a la prueba. Se instala con el Plugins Manager o copiando su jar en lib/ext, y la versión 1.3.2 se etiquetó en enero de 2026 (comprobado el 9 de octubre de 2026).

Elige otra herramienta si prefieres no mantener un plugin de terceros en cada generador de carga.

¿Y Locust y Tsung?

Locust solo llega a los WebSockets puros con código cliente que añades tú, y Tsung los soporta en su configuración XML, aunque publica versiones nuevas muy de vez en cuando. Los dos funcionan, con más esfuerzo.

Según la documentación de Locust, la herramienta solo soporta de serie HTTP y HTTPS; los demás protocolos se añaden envolviendo una biblioteca cliente y lanzando un evento request después de cada llamada. La biblioteca tiene que poder parchearse con gevent, o bloqueará todo el proceso. Para Socket.IO existe un SocketIOUser experimental. Elige Locust si tu equipo escribe Python y no le importa mantener ese código cliente.

Tsung es un proyecto en Erlang que se describe como una herramienta de pruebas de carga distribuida y multiprotocolo. Su documentación de sesiones define para WebSocket las peticiones connect, message y close, con un atributo ack para esperar una respuesta. Su última versión etiquetada, la 1.8.0, es de marzo de 2023.

¿Dónde encaja un servicio alojado como LoadFocus?

Mantener muchos sockets abiertos desde tus propias máquinas da trabajo, y un servicio alojado se encarga de generar la carga. Encaja mejor cuando tus pruebas ya son scripts de k6.

LoadFocus, el editor de este sitio, ejecuta scripts de k6 desde 25 regiones en la nube, y su página de k6 incluye las conexiones WebSocket entre las funciones de k6 que soporta. También ofrece una plantilla de prueba WebSocket con rampa de subida y bajada (en inglés). No hemos comprobado si ejecuta plugins de JMeter como WebSocket Samplers, así que no afirmamos nada al respecto.

¿Cómo elegir entre ellas?

Parte del lenguaje de tu equipo y pregúntate después si pruebas WebSockets puros o Socket.IO y con qué rigor debes comprobar los mensajes que empuja el servidor. Normalmente quedan una o dos candidatas.

Escribe en las dos la misma prueba corta de conectar, enviar y recibir, y compara el tiempo de conexión y la latencia de los mensajes con poca carga. Nuestra guía Cómo hacer una prueba de carga recorre los pasos, y el repaso de herramientas de pruebas de carga open source compara estos proyectos más allá de WebSocket.

FAQ

¿Con qué herramienta de pruebas de carga WebSocket debería empezar? Si tu equipo escribe JavaScript, empieza por k6, que trae WebSocket de serie. Para aplicaciones con Socket.IO, el motor de Artillery pide menos código, y los equipos de la JVM se sentirán como en casa con Gatling.

¿Puede JMeter probar WebSockets sin un plugin? Su referencia de componentes no incluye ningún sampler de WebSocket, así que el camino práctico es el plugin WebSocket Samplers, instalado con el Plugins Manager o como jar en lib/ext.

¿Debería usar k6/ws o k6/websockets? Usa k6/websockets para pruebas nuevas, como recomienda la documentación de k6. El módulo antiguo k6/ws sigue documentado para los scripts existentes.

Lecturas relacionadas

• Herramientas de pruebas de carga open source: seis opciones
• Prueba de carga de una API GraphQL: guía práctica
• Herramientas de benchmark HTTP: wrk, hey, oha, ab y más
• Pruebas de carga gRPC: herramientas, configuración, métricas
• Pruebas de carga con Artillery: análisis de la herramienta
• Pruebas de carga con Tsung: la herramienta Erlang a fondo

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente.