Cold starts serverless y límites de concurrencia: checklist de pruebas de carga

Serverless parece elástico hasta que cold starts y topes de concurrencia convierten un escalón de tráfico en 503. Los gráficos de latencia media ocultan distribuciones bimodales: invocaciones warm a 80 ms, cold a 2 s, throttled en error. Las pruebas deben incluir patrones idle-then-burst y respetar límites por cuenta (concurrencia Lambda AWS).

Este checklist cubre qué probar más allá de RPS plano, una rampa k6 que simula tráfico quiet-then-flash-sale, y cómo distinguir respuestas throttle de latencia cold en reportes. Combínalo con alfabetización spike vs carga cuando producto describe "tráfico súbito".

Qué probar más allá de la latencia media

Serverless difiere de contenedores always-on:

• Cold start tras ventana idle — primeras requests tras periodo quieto pagan costo de init (runtime, VPC ENI, fetch de secretos).
• Saturación de concurrencia por cuenta/región — pools reservados vs no reservados; límites burst por función.
• Comportamiento provisioned vs on-demand — concurrencia provisionada elimina camino cold para N instancias warm; prueba ambos modos si los usas.
• Timeouts downstream amplificados por invocaciones lentas — 504 de API Gateway puede ser síntoma, no causa raíz.
• Firmas 429/503 throttle distintas de errores 500 de aplicación — etiqueta y umbraliza por separado en análisis.

Piensa en capacidad serverless como tokens e instancias warm, no porcentaje CPU en flota fija.

Advertencias de fidelidad staging

Funciones en staging suelen tener más memoria, sin penalización cold VPC, o reservas de concurrencia distintas. Documenta gaps como cualquier prueba staging vs prod — los gaps serverless suelen ser mayores de lo habitual.

k6: pausa idle y spike

Ejemplo ilustrativo — no es una prueba lista para producción. Ajusta stages a tu historia de tráfico; coordina con equipo cloud el max de concurrencia antes de correr 80 req/s contra cuenta staging compartida.

Qué demuestra este ejemplo:

• ramping-arrival-rate con stage inicial bajo simula tráfico idle; rampa aguda simula flash sale o ráfaga de webhooks.
• Tags surface:serverless segmentan métricas de rutas containerizadas en el mismo gateway.
• Umbral de error relajado en fase spike opcional — documenta si la prueba busca prueba SLO o mapeo de límites.
• Sleep corto mantiene reutilización de conexión realista sin think time cero (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: {
    burst_after_quiet: {
      executor: 'ramping-arrival-rate',
      startRate: 1,
      timeUnit: '1s',
      preAllocatedVUs: 50,
      maxVUs: 200,
      stages: [
        { duration: '3m', target: 2 },
        { duration: '30s', target: 80 },
        { duration: '2m', target: 80 },
        { duration: '1m', target: 2 },
      ],
      tags: { surface: 'serverless' },
    },
  },
  thresholds: {
    'http_req_duration{surface:serverless}': ['p(95)<2000'],
    'http_req_failed{surface:serverless}': ['rate<0.05'],
  },
};

export default function () {
  const res = http.get(`${BASE}/fn/invoke`, { tags: { route: 'invoke', surface: 'serverless' } });
  check(res, {
    ok: (r) => r.status < 500,
    not_throttled: (r) => r.status !== 429 && r.status !== 503,
  });
  sleep(0.1);
}

Patrones que funcionan

• Registra cold vs warm cuando la plataforma expone x-cold-start, X-Amz-Executed-Version o similar — Trend custom en k6 si el header está presente.
• Coordina con límites de cuenta — no VUs ilimitados contra cuenta payer staging compartida.
• Corre spike durante ventana con personal — aborta si tasa throttle supera límite de exploración acordado.
• Compara provisioned on/off en dos exports — liderazgo ve trade-off costo vs latencia.

Anti-patrones a evitar

• Solo constant-arrival-rate plano — nunca ejercita camino cold tras idle.
• Tratar todos los 503 como bugs de aplicación — puede ser throttle de concurrencia.
• Stress en Lambda producción sin control de cambios y plan de reserva de concurrencia.
• Ignorar límites de conexión DB downstream cuando funciones escalan rápido.

Pro tip (comando de ejemplo): desglosa códigos de estado en resumen para análisis de throttle.

k6 run serverless-burst.js --summary-trend-stats="p(95),p(99)" --tag surface=serverless

Qué demuestra este comando: combina con filtro post-run de http_req_duration donde status=503 en tu herramienta de análisis — separa latencia cold de throttle duro.

Marco de decisión: patrón vs executor

Usa rampa con forma spike antes de eventos de marketing — no otra corrida de carga steady.

Usa ARR steady solo tras confirmar pool warm — si no, cold sesga p95.

Observabilidad y checklist pre-corrida

• Registra cold vs warm si la plataforma expone headers diagnósticos — anota en reporte.
• Coordina max concurrencia con equipo cloud — documenta límites cuenta/región.
• Compara tipo de prueba spike vs carga con lenguaje de producto.
• Separa throttle vs 5xx de aplicación en checks o post-procesamiento.
• Anota conteo de concurrencia provisionada y settings de memoria en pie de reporte.
• Programa durante ventana donde on-call puede desactivar prueba vía kill switch.

Cómo Performate simplifica las pruebas de carga serverless

Abajo hay un ejemplo de flujo concreto para prueba de burst en URL invoke — adapta stages a tu perfil flash-sale.

Ejemplo: plantilla spike cold-start

1. Importa URL invoke desde Postman — headers y auth preservados. Problema resuelto: sin reescribir paths API Gateway bajo presión de lanzamiento.
2. Construye stages de rampa en UI — 3m quiet, 30s spike, 2m hold. Problema resuelto: editor visual de stages reduce errores YAML en semanas de alto estrés.
3. Corre burst en staging con equipo cloud en Slack. Problema resuelto: abort en escritorio más rápido que esperar cancel de job CI.
4. Filtra errores por status en reporte — 429/503 vs 500. Problema resuelto: ticket de capacidad recibe evidencia throttle, no genérico "subieron errores".
5. Exporta para ticket de capacidad con captura de diagrama de stages. Problema resuelto: debate concurrencia provisionada/finanzas usa un artefacto.
6. Guarda plantilla para próximo lanzamiento — retag solo surface:serverless. Problema resuelto: repetibilidad sin reconstruir de memoria.

Ese flujo mapea directamente al cta de este post: escenarios ejecutables y reportes compartibles sin pánico de código de integración antes del lanzamiento.

Cierre

Las pruebas de carga serverless son idle + burst + límites, no RPS plano. Programa un spike cold-start antes del próximo flash sale; etiqueta throttles por separado; documenta reservas de concurrencia en el mismo ticket que el export k6.

Coordina con tu equipo cloud, corre quiet-then-spike una vez en staging y registra dónde empiezan los 429 — ese número pertenece al runbook de lanzamiento.

Try Performate free | Book a demo | Executors k6