SSE y long-polling bajo carga: patrón práctico de prueba con k6

Los dashboards que usan SSE o long-polling y se cuelgan bajo streams concurrentes fallan de forma distinta a las ráfagas REST: dominan los timeouts idle del proxy, los topes de conexión y el buffer bloat (MDN SSE, HTTP keep-alive). Un pico de GETs cortos no dice nada sobre diez mil streams abiertos detrás del mismo balanceador.

k6 puede abrir conexiones HTTP de larga duración; hay que modelar conteo de streams concurrentes y duración de requests largos, no solo RPS de GETs de menos de un segundo. En esta guía verás modos de fallo, un patrón de VUs concurrentes con timeouts extendidos y cuándo comparar con patrones de carga WebSocket.

Modos de fallo bajo streams concurrentes

Las UIs orientadas a eventos y los feeds en vivo estresan infraestructura que los benchmarks REST no tocan:

• El proxy cierra conexiones idle a los 60 s mientras el servidor cree que el stream sigue abierto: la tormenta de reconexiones amplifica la carga.
• Agotamiento de descriptores de archivo en gateways e ingress: los errores parecen 502 aleatorios.
• Fan-out: un evento del servidor dispara N polls de clientes o fetches downstream—multiplica la carga más allá del conteo de VUs de k6.
• Buffer bloat en consumidores lentos: la memoria sube en intermediarios mientras k6 sigue recibiendo 200.
• Límites de reutilización de conexión HTTP/1.1 por host—el conteo de VUs no es igual al de pestañas del navegador, pero la dirección es similar.

El long-polling difiere ligeramente: GETs largos repetidos por ciclo de VU en lugar de un stream infinitamente abierto—modela ambos si el producto usa patrones híbridos.

SSE vs WebSocket vs long-poll

Patrón k6: GET largo con timeout extendido

Ilustrativo—no listo para producción. El cliente HTTP de k6 lee el body completo por defecto; para validación de parser SSE de grado producción considera herramientas complementarias o extensiones xk6. Este patrón sigue estresando tablas de conexión y timeouts de proxy.

Qué demuestra este ejemplo:

• constant-vus equivale a streams abiertos concurrentes—ajusta STREAM_VUS a viewers en vivo esperados, no a RPS REST.
• timeout extendido en http.get—120 s de ejemplo; alinea con hold de long-poll del servidor + margen.
• Header Accept: text/event-stream—misma ruta que usan los navegadores.
• Tags protocol:sse separan umbrales de escenarios REST en suites mixtas.

import http from 'k6/http';
import { check, sleep } from 'k6';

const BASE = __ENV.API_BASE || 'https://staging.example.com';

export const options = {
  scenarios: {
    sse_clients: {
      executor: 'constant-vus',
      vus: Number(__ENV.STREAM_VUS || 100),
      duration: '5m',
      tags: { protocol: 'sse' },
    },
    rest_baseline: {
      executor: 'constant-arrival-rate',
      rate: 20,
      timeUnit: '1s',
      duration: '5m',
      tags: { protocol: 'rest' },
    },
  },
  thresholds: {
    http_req_failed: ['rate<0.02'],
    'http_req_duration{protocol:sse}': ['p(95)<5000'],
    'http_req_duration{protocol:rest}': ['p(95)<400'],
  },
};

export default function () {
  const res = http.get(`${BASE}/events/stream`, {
    headers: { Accept: 'text/event-stream' },
    timeout: '120s',
    tags: { route: 'stream', protocol: 'sse' },
  });
  check(res, { connected: (r) => r.status === 200 });
  sleep(Number(__ENV.RECONNECT_SEC || 5));
}

Patrones que funcionan

• Rampa de VUs por stages—encuentra la rodilla del límite de conexiones antes del conteo completo de viewers.
• Alinear timeouts idle de proxy/load balancer en el runbook—si el proxy mata a 60 s, no uses timeout de 120 s sin esperar churn de reconexión.
• Monitorizar FDs abiertos en el gateway durante la prueba—aborta si la pendiente es lineal.
• Escenarios REST y SSE separados—no mezcles umbrales; los modos de fallo difieren.

Anti-patrones a evitar

• Medir solo health REST corto mientras el dolor en producción son streams concurrentes.
• Poner VUs igual a números de RPS REST—los streams son conexiones concurrentes, no req/s.
• Ignorar tormentas de reconexión tras timeout de proxy—la segunda ola puede superar la primera.
• Correr el conteo completo de viewers en producción sin control de cambios.

Pro tip (comando de ejemplo): rampa VUs de stream para encontrar la rodilla.

k6 run sse-load.js --env STREAM_VUS=50 --duration 3m --tag protocol=sse

Qué demuestra este comando: pruebas incrementales de VUs en escritorio localizan límites de FD del gateway antes de programar el ensayo completo de 5k streams con platform on-call.

Marco de decisión: patrón vs modelo de carga

Corre escenario REST baseline en paralelo—demuestra que la API sigue sana mientras los streams están abiertos. Algunos equipos solo rompen REST cuando la tabla de conexiones está llena.

Observabilidad y checklist pre-corrida

• Timeouts idle de proxy/load balancer documentados en el runbook.
• Monitorizar FDs abiertos y conteo de conexiones en el gateway durante la prueba.
• Abortar si la tasa de error sube en los primeros 10 minutos—no quemar staging ciegamente.
• Coordinar con el equipo de red—ingress compartido puede afectar servicios no relacionados.
• Anotar limitaciones HTTP de k6 para parsing de eventos—documentar si la prueba es solo conexión vs validación de payload.
• Comparar resultados con la ruta WebSocket si el producto evalúa migración.

Cómo Performate apoya pruebas SSE/long-poll

Abajo hay un ejemplo concreto de flujo para carga del endpoint de stream—adapta conteos de VU a tu pico de viewers concurrentes.

Ejemplo: rampa de VUs de stream con export para networking

1. Importa el endpoint de stream desde Postman—headers incluyendo Accept. Problema resuelto: la misma ruta que QA usa funcionalmente se convierte en objetivo de carga.
2. Configura escenario VU + timeout largo en la UI—120 s o según runbook. Problema resuelto: evita editar strings de timeout a mano en cada iteración.
3. Corre rampa por stages en VUs—50, 100, 200 con tripwires de abort. Problema resuelto: encuentra la rodilla antes del ensayo a escala completa.
4. Exporta timeouts y errores de conexión filtrados por protocol:sse. Problema resuelto: el equipo de plataforma recibe desglose por código de estado, no un genérico «lento».
5. Comparte el export con platform—captura de FDs con el mismo timestamp. Problema resuelto: el ticket de capacidad enlaza la prueba de app con evidencia de infra.
6. Guarda plantilla para release—retag protocol:sse por evento. Problema resuelto: repite antes de cada lanzamiento de dashboard en vivo.

Ese flujo encaja con el cta de este post: escenarios de conexión larga ejecutables sin semanas de glue code.

Cierre

La carga SSE/long-poll es un problema de presupuesto de conexiones: rampa streams concurrentes, alinea timeouts con reglas de proxy y nunca mezcles umbrales SSE con baselines REST.

Programa una rampa de VUs esta semana en staging, observa métricas de conexión del gateway durante la corrida y anota el conteo de VU donde empiezan los errores—ese número pertenece al checklist de lanzamiento.

Try Performate free | Book a demo | HTTP k6