Línea base vs regresión: construir un benchmark de rendimiento repetible para APIs

El release 412 “se veía bien” en QA hasta que p99 de checkout subió 180 ms sobre el sobre acordado en marzo—porque nadie reejecutó el mismo escenario k6 con los mismos datos y tags. Una línea base es el sobre aceptado de latencia y error para un escenario bajo un contrato de entorno conocido. Una regresión es una deriva significativa de ese sobre tras un cambio. Sin ADN de escenario congelado, comparas ficción.

En esta guía verás qué bloquear en un bundle de línea base, cómo codificar gates con thresholds de k6, cuándo resetear líneas base tras cambios de infra y cómo guardar corridas comparables para que la rotación de ingenieros no borre la memoria.

Por qué fallan las líneas base antes que los umbrales

Los equipos copian un script, ajustan VUs “por las dudas” y se preguntan por qué los gráficos nocturnos no coinciden. Deriva pequeña invalida comparaciones:

• Executor distinto (constant-vus vs arrival-rate) cambia quién espera en colas.
• Deriva de payload o auth altera CPU y tamaño de respuesta sin cambio en el servicio bajo prueba.
• Cambio de fingerprint de entorno (snapshot DB, caché caliente, flags) mueve colas independiente del merge.

La práctica de la industria ata niveles de servicio a SLIs que el usuario siente (Google SRE workbook); k6 los codifica como umbrales etiquetados en http_req_duration y http_req_failed. Revisa errores comunes en pruebas de carga antes de confiar en un umbral rojo e integra smoke gates en pruebas de carga en CI/CD cuando la línea base esté estable.

Empareja disciplina de línea base con ejemplos de umbrales k6 al añadir rutas o dependencias.

Implementación práctica en k6: ADN congelado, tags de build y gates

Trata el script de línea base como artefacto versionado: parámetros de escenario, variables de entorno, datasets y líneas de umbral viajan juntos.

Script de ejemplo (ilustrativo—no listo para producción). API checkout ficticia y números de sobre.

Qué demuestra este ejemplo:

• Fingerprint por env BUILD_ID en tags para comparar corridas de CI.
• Escenario dorado único con constant arrival rate—presión de requests estable semana a semana.
• Umbrales que fallan la corrida cuando colas o errores rompen el sobre registrado.
• Duración apta para smoke nocturno; extiende para re-baselining trimestral.

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

const BASE = __ENV.API_BASE || 'https://staging.example.com';
const BUILD = __ENV.BUILD_ID || 'local';
const body = JSON.stringify({ sku: 'SKU-100', qty: 1, currency: 'USD' });

export const options = {
  scenarios: {
    baseline_checkout: {
      executor: 'constant-arrival-rate',
      rate: Number(__ENV.BASELINE_RPS || 25),
      timeUnit: '1s',
      duration: __ENV.BASELINE_DURATION || '10m',
      preAllocatedVUs: 25,
      maxVUs: 100,
      tags: { route: 'checkout', profile: 'baseline' },
      exec: 'checkout',
    },
  },
  thresholds: {
    'http_req_duration{route:checkout}': ['p(95)<750', 'p(99)<1100'],
    http_req_failed: ['rate<0.008'],
  },
};

export function checkout() {
  const res = http.post(`${BASE}/v2/checkout`, body, {
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${__ENV.TOKEN}`,
    },
    tags: { route: 'checkout', build: BUILD, profile: 'baseline' },
  });
  check(res, { 'checkout 2xx': (r) => r.status >= 200 && r.status < 300 });
  sleep(0.35);
}

Patrones que funcionan

• Guardar JSON de resumen crudo + git SHA + fingerprint de env junto a cada captura verde.
• Fallar merges por breach de umbral; usar revisión más suave de delta p95 en weeklies con muestra suficiente—smokes cortos son ruidosos.
• Etiquetar build en requests para comparaciones en Performate o k6 Cloud (k6 observabilidad métricas y tags).
• Documentar renovación de línea base en el changelog cuando infra o trades intencionales muevan el sobre.

Antipatrones a evitar

• Cambiar RPS y duración la misma semana que comparas builds—un solo eje por experimento.
• Resetear umbrales en silencio tras un run fallido “para quedar verde”.
• Comparar línea base de staging con forma de tráfico de producción sin anotación.

Pro tip (comando de ejemplo): export JSON para archivo y diffs.

k6 run baseline-checkout.js -e BUILD_ID=$CI_COMMIT_SHA -o baseline-summary.json

Qué demuestra este comando: salida legible por máquina adjunta al registro del build para diffs, no debates de capturas.

Marco de decisión: captura vs gate de regresión vs reset

Captura línea base nueva si cambiaste ADN del escenario a propósito y los stakeholders aceptan un sobre nuevo.

Trata como regresión si el ADN no cambió y colas o errores etiquetados cruzan umbrales—investiga antes de ensanchar gates.

Resetea dashboards solo tras notas de renovación explícitas—si no, on-call persigue números de marzo en infra de julio.

Observabilidad, documentación y próximos pasos

Antes del próximo tren de releases:

• Congelar documento de ADN: executor, duración, RPS, mix de payload, think time, versión de dataset.
• Registrar fingerprint de entorno (id snapshot DB, flags, procedimiento de caché).
• Archivar JSON de resumen verde con git SHA al capturar líneas base.
• Conectar fallo de umbral a bloqueo de merge en CI para el escenario dorado.
• Comparar deltas p95/p99 entre corridas nocturnas con reglas de muestra mínima.
• Registrar eventos de renovación de línea base con dueño y motivo.

Cómo Performate mantiene líneas base comparables entre releases

Definiciones de escenario dispersas en laptops no sobreviven rotación. Centraliza el path dorado y los exports.

Ejemplo: línea base de checkout por build

1. Importar el flujo Postman dorado (u operación OpenAPI) usado en la captura de marzo. Problema resuelto: una definición para local, CI y revisiones.
2. Configurar constant arrival rate al BASELINE_RPS registrado (p. ej. 25 req/s) y duración 10m en el editor. Problema resuelto: ADN del escenario en un workspace, no cinco forks.
3. Aplicar tags route:checkout, profile:baseline y pasar BUILD_ID desde env de CI en scripts exportados. Problema resuelto: vistas de comparación filtran las mismas dimensiones.
4. Introducir umbrales del sobre archivado (p95, p99, tasa de error). Problema resuelto: edición visual de gates sin deriva entre copias del script.
5. Ejecutar en cada candidato a release y abrir comparación histórica en el reporte integrado. Problema resuelto: producto e ingeniería debaten un export por build.
6. Exportar k6 para smoke en pipeline a menor duración/RPS con mismos tags y expresiones de umbral—escala tiempo, no forma.

Ese flujo cumple el cta: guardar corridas comparables y resultados de umbrales entre releases sin gráficos pera con manzana.

Cierre

La disciplina de línea base de rendimiento de API es ADN de escenario congelado más umbrales honestos. La detección de regresión solo es confiable cuando forma de tráfico, datos, tags y fingerprint coinciden con el run verde capturado—luego deja que k6 falle el build cuando las colas se muevan.

Reejecuta tu escenario dorado de checkout en el candidato actual con BUILD_ID—anota si necesitas un fix o una renovación documentada de línea base.

Try Performate free | Book a demo | k6 results output