Throughput vs latencia: cómo presentar resultados que los stakeholders entiendan

Ejecutivos preguntan «¿cuántas peticiones por segundo?» e ingeniería defiende p99—y ambos salen confundidos cuando RPS sube y la UX empeora. Throughput y latencia cuentan historias distintas; mezclarlas erosiona confianza en programas de rendimiento y lleva a malas apuestas de capacidad.

Intuición Ley de Little: en estado estable, concurrencia media ≈ tasa de llegada × tiempo de respuesta medio. Más RPS con capacidad fija suele significar colas más largas—muestra throughput y percentiles en la misma slide con la misma duración de prueba y nota de entorno.

Esta guía mapea métricas a audiencias, da un patrón de tags k6 para exports centrados en checkout e incluye tabla de decisión para las preguntas que stakeholders hacen en readouts.

Qué graficar para quién

Audiencias distintas necesitan cortes distintos de la misma corrida k6—nunca un solo gráfico forzado para todos:

• Liderazgo: pass/fail SLO al RPS declarado, p95/p99 vs objetivo, tendencia vs release anterior, caveat de fidelidad de entorno en una línea.
• Producto: latencia por journey (checkout, envío de búsqueda)—no promedio global del servicio que oculta pasos lentos.
• Ingeniería: RPS logrado, errores por tag route, señales de saturación de APM, checks fallidos.
• Finanzas/capacidad: RPS máximo cumpliendo SLO con % de headroom—no RPS pico solo.

No presentes solo promedio de http_req_duration—la media oculta dolor de cola (p95 vs p99). No presentes RPS pico sin decir si los SLO siguieron pasando a esa tasa.

La nota al pie que salva tu credibilidad

Cada slide para stakeholders necesita: RPS, duración, entorno, datos sintéticos sí/no. Notas faltantes generan leyendas «staging dijo 2k RPS» en postmortems de producción (staging vs prod).

k6: tags amigables para export

Segmenta checkout (o tu camino de ingresos) para slides de producto; mantén tag report:exec para filtrar exports de la misma corrida que usa ingeniería.

Ejemplo (ilustrativo). ARR estable con umbrales específicos por ruta.

Qué demuestra este ejemplo:

• constant-arrival-rate fija RPS de negocio—el número de liderazgo coincide con config de prueba.
• Umbrales solo en route:checkout—slide de producto no contaminada por health checks.
• Tag report:exec filtra secciones PDF de Performate para plantilla de liderazgo.
• Think time incluido—RPS honesto vs requests ametralladora (sanity VUs).

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

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

export const options = {
  scenarios: {
    steady: {
      executor: 'constant-arrival-rate',
      rate: Number(__ENV.RPS || 50),
      timeUnit: '1s',
      duration: '5m',
      preAllocatedVUs: 25,
      maxVUs: 100,
      tags: { report: 'exec' },
    },
  },
  thresholds: {
    'http_req_duration{route:checkout}': ['p(95)<800', 'p(99)<1200'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  http.get(`${BASE}/catalog`, { tags: { route: 'browse' } });
  sleep(1);
  const res = http.post(`${BASE}/checkout`, '{}', {
    headers: { 'Content-Type': 'application/json' },
    tags: { route: 'checkout', report: 'exec' },
  });
  check(res, { ok: (r) => r.status < 500 });
  sleep(0.5);
}

Patrones que funcionan

• Dos gráficos: throughput (RPS logrado) + percentiles a ese RPS—misma corrida, mismo pie.
• Antes/después al mismo RPS para comparaciones de release—claims de «más rápido» exigen RPS controlado.
• Enlaza presupuestos de rendimiento cuando latencia UI forma parte del SLO del journey.
• Filtra Performate por route:checkout antes de export PDF—readout de producto en un clic.

Anti-patrones a evitar

• Presumir RPS pico de stress test donde errores superaron SLO—throughput sin calidad es ruido.
• Mezclar corridas load y spike en una línea de tendencia—formas distintas (stress vs carga vs spike).
• Slide ejecutiva solo con latencia media—usuarios de cola generan tickets de soporte.
• Comparar RPS staging de esta semana con slide de producción del mes pasado—mismatch de entorno.

Pro tip (comando de ejemplo): resumen centrado en percentiles para apéndice ejecutivo.

k6 run stakeholder-run.js --summary-trend-stats="p(95),p(99),avg" --tag report=exec

Qué demuestra este comando: el bloque summary pega en apéndice con cola y media—revisores ven que no cherry-pickeaste solo promedio.

Marco de decisión: pregunta del stakeholder vs respuesta

Lidera con percentiles SLO al RPS declarado—throughput es contexto, no titular, salvo que la pregunta sea explícitamente headroom de capacidad.

Observabilidad y checklist de reporte

• Una página: RPS elegido, duración, nota de fidelidad de entorno, confirmación datos sintéticos.
• Gráficos separados para throughput logrado y percentiles—mismo ID de corrida.
• Enlace a presupuestos frontend+API cuando UI involucrada en journey.
• Archiva export con SHA de release—comparación semana a semana en Performate.
• Ruta de producto etiquetada (route:checkout)—no solo http_req_duration global.
• Spike vs load etiquetados si hay múltiples corridas en deck—no mezclar tipos de prueba.

Cómo Performate apoya reportes para stakeholders

Abajo hay un ejemplo concreto de flujo para reporte ejecutivo de checkout—adapta rutas a tu camino de ingresos.

Ejemplo: una corrida, dos exports

1. Corre escenario estable al RPS acordado—5m mínimo para percentiles estables. Problema resuelto: número de liderazgo ligado a config real de prueba, no cálculo de servilleta.
2. Filtra reporte por route:checkout y tag report:exec. Problema resuelto: slide de producto excluye rutas no relacionadas de la misma corrida.
3. Exporta PDF con tendencias de percentiles + pie RPS incluido. Problema resuelto: sin errores de transcripción manual a hoja de cálculo.
4. Duplica plantilla de slide—RPS + p99 + pass/fail vs doc SLO. Problema resuelto: readouts consistentes trimestre a trimestre.
5. Archiva con SHA de release junto al export completo de ingeniería. Problema resuelto: trazabilidad cuando alguien pregunta «¿qué build era?»
6. Presenta vista comparativa semana a semana al mismo RPS—no formas mezcladas. Problema resuelto: «¿somos más rápidos?» respondido con honestidad.

Ese flujo encaja con el cta de este post: simplificar el camino desde corrida k6 hasta evidencia lista para stakeholders.

Cierre

Reportes listos para stakeholders empiezan con percentiles SLO a RPS declarado, no con presunción de throughput. Arregla la nota al pie de RPS, separa gráficos y etiqueta rutas de ingresos antes del próximo readout ejecutivo.

Toma tu último export k6, añade RPS y entorno a slide uno, y mueve throughput pico al apéndice donde corresponde.

Try Performate free | Guides | Book a demo