Usuarios virtuales, think time y sugerencias de IA: chequeos de sanidad antes de correr

A la IA le encanta sleep(0) y 500 VUs porque impresiona en el script. Luego los stakeholders creen que probaste «500 usuarios» cuando en realidad disparaste RPS irreal en un bucle cerrado sin think time—señales de capacidad falsas, fallos falsos y decisiones de release construidas sobre ficción.

Antes de correr cualquier escenario k6 sugerido por IA, revisa el modelo de executor, conteo de VUs vs tasa de llegada y distribución de sleep contra analytics (executors k6). Esta guía explica modelos abierto vs cerrado, reglas de think time, un ejemplo k6 browse→cart realista y un checklist de revisión IA que tu equipo puede pegar en cada ticket de perf.

Modelos abierto vs cerrado

La elección del executor es un modelo del mundo, no una preferencia de sintaxis:

• Cerrado (constant-vus, ramping-vus): usuarios concurrentes fijos; el RPS emerge del tiempo de respuesta. Si el sistema se ralentiza, cada usuario espera más pero sigue activo—el RPS puede caer O el encolado por usuario aumenta carga de formas que producto no describió.
• Abierto (constant-arrival-rate, ramping-arrival-rate): RPS de negocio fijo; los VUs escalan con la latencia. Encaja con «500 pedidos por minuto» o «API checkout a 40 req/s».

Elige el modelo que coincida con cómo producto y analytics describen la carga (stress vs carga). Si el ticket dice «500 compradores concurrentes navegando», cerrado puede encajar. Si dice «500 checkouts por minuto», abierto es obligatorio.

Señales de alerta en borradores IA

• VUs > 10× RPS objetivo sin think time largo—implica requests ametralladora.
• sleep(0) en rutas de escritura—revisar siempre.
• constant-vus cuando la cita de producto era estrictamente RPS—desajuste de executor.
• Falta setup() para auth que la IA quitó «por simplicidad».

Reglas de think time

El think time moldea el RPS implícito más que el conteo de VUs en modelos cerrados:

• Usa mediana de tiempo entre clics desde logs o analytics—no cero porque k6 se sintió lento.
• Añade jitter—sleep(2 + Math.random()) evita olas sincronizadas que crean picos artificiales.
• Sleeps distintos en lectura vs escritura—navegar más que POST confirm.
• Documenta think time asumido en el pie del reporte—stakeholders comparan corridas con justicia.

RPS implícito (modelo cerrado, aproximado): VUs / (avg_response_time + think_time). Corre piloto de un minuto y compara RPS implícito con analytics antes de escalar duración.

Ejemplo k6 de sanidad

Ejemplo (ilustrativo). Browse→cart con ARR y think time con jitter.

Qué demuestra este ejemplo:

• constant-arrival-rate define carga de negocio—la declaración de RPS de producto mapea directamente.
• preAllocatedVUs / maxVUs como topes—k6 escala VUs sin goroutines ilimitadas en el cliente.
• Sleep con jitter tras browse—ritmo realista, no martilleo sincronizado.
• Tags separados en browse vs cart para segmentación en reportes.

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

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

export const options = {
  scenarios: {
    realistic: {
      executor: 'constant-arrival-rate',
      rate: Number(__ENV.TARGET_RPS || 20),
      timeUnit: '1s',
      duration: '5m',
      preAllocatedVUs: 10,
      maxVUs: 80,
      tags: { ai: 'reviewed' },
    },
  },
  thresholds: {
    'http_req_duration{route:cart}': ['p(95)<900'],
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  http.get(`${BASE}/browse`, { tags: { route: 'browse' } });
  sleep(2 + Math.random()); // think time ~2–3s
  const res = http.post(`${BASE}/cart`, '{}', {
    headers: { 'Content-Type': 'application/json' },
    tags: { route: 'cart' },
  });
  check(res, { ok: (r) => r.status < 500 });
  sleep(1);
}

Patrones que funcionan

• Piloto de un minuto al executor objetivo—compara RPS implícito y tasa de error antes de corrida de 10m.
• Bloquear executor en UI tras borrador IA—el editor visual de Performate evita cambio accidental de modelo.
• Tag ai:reviewed solo tras paso de sanidad humana—empareja con seguimiento ROI.
• Pregunta a producto: «¿RPS o usuarios concurrentes?»—documenta respuesta en ticket.

Antipatrones a evitar

• Correr salida IA cruda en staging compartido a VUs completos—valida piloto primero.
• Usar VUs cerrados para prueba de SLO ARR—desajuste de modelo invalida la historia del umbral.
• Quitar sleeps para «ahorrar tiempo CI»—señal falsa no ahorra nada.
• Confiar en umbrales propuestos por IA sin cruce con doc de SLO.

Pro tip (comando de ejemplo): corrida piloto con summary JSON para chequeo de RPS implícito.

k6 run sanity-browse-cart.js --duration 1m --env TARGET_RPS=20 --summary-export=pilot.json

Qué demuestra este comando: piloto de un minuto produce conteo de iteraciones y stats de duración—divide iteraciones completadas entre 60 para RPS logrado aproximado vs ARR objetivo antes de comprometer corrida larga.

Marco de decisión: lenguaje de producto vs executor

Checklist de revisión IA

Antes de escalar cualquier escenario sugerido por IA:

• ¿Producto habla en RPS o usuarios concurrentes? Executor coincide.
• ¿VUs > RPS sin think time largo? Marcar y corregir.
• ¿La IA quitó auth/setup? Restaurar desde import Postman.
• Comparar RPS implícito con capacidad staging y banda de analytics.
• Think time documentado en ticket y pie de reporte.
• Tag ai:reviewed solo tras sign-off humano (gobernanza donde aplique).

Cómo Performate apoya chequeos de sanidad antes de escalar

Abajo hay un ejemplo de flujo concreto para revisar flujo browse/cart borrado por IA—adapta a tu colección.

Ejemplo: import → borrador IA → bloqueo humano → piloto

1. Importa colección Postman real—requests browse y cart ordenados. Problema resuelto: la IA no puede inventar rutas cuando import es paso obligatorio primero.
2. Deja que IA borre estructura de escenario—bloquea executor a ARR manualmente en UI. Problema resuelto: evita defaults constant-vus impresionantes pero incorrectos.
3. Configura campos think time desde nota de analytics—2–3s browse, 1s post-cart. Problema resuelto: editor visual más rápido que cazar líneas sleep() que la IA dispersó.
4. Corre piloto 1m; lee RPS logrado en reporte. Problema resuelto: detecta errores de modelo antes de reserva de staging de treinta minutos.
5. Compara carga implícita con banda de analytics—ajusta rate o sleep. Problema resuelto: stakeholders confían en números ligados al lenguaje de producto.
6. Aplica tag ai:reviewed y corre 5m completo—archiva export para camino de promoción CI. Problema resuelto: trazabilidad de auditoría de borrador a corrida aprobada.

Ese flujo mapea directamente al cta de este post: publicar más rápido sin saltar validación en VUs, think time y executors.

Cierre

No corras números crudos de VU de IA. Traduce lenguaje de producto a executors, añade think time con jitter, pilota un minuto y luego escala duración—tag ai:reviewed solo tras que un humano apostaría su nombre por la config.

Abre tu último script borrado por IA, comprueba executor vs cita de producto y corre piloto de un minuto antes de la próxima ventana completa de staging.

Try Performate free | Book a demo | ROI flujos IA