---
title: "Throughput vs latencia: cómo presentar resultados que los stakeholders entiendan"
description: "Throughput vs latencia para ejecutivos: une RPS de k6 a historias de percentiles—intuición de la Ley de Little y reportes orientados a SLO."
publishDate: "2026-09-24"
draft: false
keyword: "throughput vs latencia"
intent: "TOFU"
cta: "Explora cómo Performate simplifica las pruebas de carga con k6, desde imports hasta resultados, para que tu equipo publique con más confianza en rendimiento."
tags: ["k6", "pruebas-de-carga", "rendimiento-api", "throughput", "latencia"]
translationOf: throughput-vs-latency-stakeholders
---

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](https://es.wikipedia.org/wiki/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](/es/blog/p95-vs-p99-latencia)). 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](/es/blog/pruebas-carga-staging-vs-produccion)).

## 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](/es/blog/usuarios-virtuales-think-time-chequeos-ia)).

```javascript
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](/es/blog/presupuesto-rendimiento-frontend-api)** 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](/es/blog/stress-vs-carga-vs-spike-testing)).
- 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.

```bash
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

| Pregunta | Responde con | No respondas con |
|:---|:---|:---|
| «¿Somos más rápidos?» | `p95`/`p99` vs baseline al **mismo RPS** | RPS pico de tipo de prueba distinto |
| «¿Aguantamos más usuarios?» | RPS máximo cumpliendo SLO + % headroom | Conteo VU sin think time |
| «¿El release ayudó?» | Mismo RPS antes/después, compara percentiles | Duraciones o entornos distintos |
| «¿Listos para lanzamiento?» | Tabla pass/fail carga + spike con fechas | Un solo smoke de staging |
| «¿Por qué lento si RPS está bien?» | Historia de cola Ley de Little + métricas saturación | Culpar «la nube» sin datos |

**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](/es/blog/presupuesto-rendimiento-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](https://performate.app) | [Guides](/guides) | [Book a demo](/demo)