Planificador de Tests de Rendimiento

El Problema

Tu aplicacion funciona genial con 10 usuarios. Pero que pasa con 1,000? O 10,000? Los problemas de rendimiento — queries lentos de base de datos, memory leaks, agotamiento del pool de conexiones — solo aparecen bajo carga. La mayoria de los equipos descubren estos problemas en produccion durante un pico de trafico en vez de en un entorno de test controlado. Planificar tests de rendimiento requiere entender patrones de trafico, definir umbrales significativos y elegir las herramientas correctas, lo cual es un conocimiento especializado que la mayoria de desarrolladores no tiene.

El Prompt

Crea un plan de testing de rendimiento para mi aplicacion. Necesito saber como se comporta bajo carga realista antes de que llegue a produccion.

APLICACION:
[describe tu app — tipo, trafico esperado, stack tecnologico, infraestructura]

METRICAS ACTUALES (si se conocen):
[ej. "P95 tiempo de respuesta: 400ms, 500 RPM promedio, 2000 RPM pico"]

HERRAMIENTA PREFERIDA: [k6 / Artillery / Locust / JMeter / Gatling]

Genera:

1. **Modelo de Trafico** — Definir patrones de trafico realistas:
   - Carga normal (trafico diario sostenido)
   - Carga pico (campana de marketing, lanzamiento de producto)
   - Test de spike (explosion de trafico 10x repentina)
   - Test de duracion (carga sostenida de 4-8 horas para encontrar memory leaks)

2. **Umbrales de Rendimiento** — Definir criterios de aprobado/fallido:
   - P95 tiempo de respuesta por endpoint
   - Porcentaje de tasa de error
   - Throughput (requests por segundo)
   - Limites de utilizacion de recursos (CPU, memoria, conexiones)

3. **Scripts de Test** — Escribir los scripts de test de carga para los top 3 endpoints criticos con:
   - Tiempo de pensamiento realista entre requests
   - Patrones de ramp-up y ramp-down correctos
   - Metricas custom para operaciones criticas del negocio
   - Parametrizacion de datos (no el mismo usuario/request cada vez)

4. **Integracion CI** — Mostrar como ejecutar tests de rendimiento en CI con aprobado/fallido automatico basado en umbrales.

Ejemplo de Salida

// k6 test de carga para API de checkout
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },  // ramp up
    { duration: '5m', target: 100 },  // sostener
    { duration: '2m', target: 500 },  // pico
    { duration: '1m', target: 0 },    // ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<800', 'p(99)<1500'],
    http_req_failed: ['rate<0.01'],
  },
};

Cuando Usar

Usar antes de un lanzamiento grande, despues de cambios significativos de infraestructura, o cuando sospechas regresiones de rendimiento. Ejecutar tests de duracion antes de cada release para atrapar memory leaks que solo aparecen despues de horas de carga sostenida. Integrar tests de rendimiento basados en umbrales en CI para detectar regresiones temprano.

Tips Pro

• Modelar comportamiento real del usuario — pedir a la IA que analice tus logs de acceso y genere un modelo de trafico que coincida con patrones de uso reales.
• Testear la base de datos, no solo la API — incluir deteccion de queries lentos y monitoreo del pool de conexiones en tus tests de rendimiento.
• Comparar contra baselines — almacenar resultados de cada ejecucion y pedir a la IA que analice tendencias: “P95 esta subiendo en las ultimas 10 ejecuciones?”
• Testear modos de fallo — incluir escenarios donde una dependencia esta lenta o caida para verificar degradacion elegante.