Prueba de carga¶

AC-39 exige 200 req/s sostenidos durante 5 minutos contra el jar, primero con la base activa y luego con la base detenida, verificando que el p99 del servidor se mantenga bajo 20 ms. Script: tools/load/load.py.

Por qué mide con la métrica del servidor, no del cliente¶

El veredicto de AC-39 se mide con la métrica del servidor resolver.latencia (la métrica de éxito del SPEC), no con el ida y vuelta del cliente de carga. Por eso hay que pasar --admin-user/--admin-password: load.py necesita leer /actuator/prometheus antes y después de la corrida para calcular el delta de los buckets del histograma.

python tools/load/load.py --base-url http://localhost:8080 --api-key <clave-gateway> \
    --rps 200 --seconds 300 \
    --admin-user admin --admin-password <clave-admin>

Corrida con la base detenida¶

Para confirmar INV-O01/INV-O02 (la respuesta no espera a la base; la pérdida de auditoría se cuenta):

python tools/load/load.py --base-url http://localhost:8080 --api-key <clave-gateway> \
    --rps 200 --seconds 300 --db-down-check \
    --admin-user admin --admin-password <clave-admin>

Ambas corridas escriben reports/load-<timestamp>.md (resumen legible) y tools/reports/junit-load.xml (un testcase "AC-39 sustained load p99 under 20ms"). La corrida con la base detenida además imprime si auditoria_perdidas_total (de /actuator/prometheus) quedó en > 0.

Regla del veredicto (AC-39)¶

El testcase pasa si y solo si no hubo errores y el p99 del servidor (calculado del delta de los buckets de resolver_latencia_seconds_bucket entre el scrape de antes y el de después) es <= 20 ms.

Si la métrica del servidor no está disponible —no se pasaron credenciales de admin, o /actuator/prometheus no respondió durante la corrida— el testcase falla con un mensaje que dice que la métrica del servidor es obligatoria; nunca cae de vuelta al p50/p95/p99 del cliente. Esos valores del cliente se siguen informando en el reporte Markdown y en la salida estándar, pero son informativos únicamente: en un host compartido con el servidor incluyen el overhead propio del cliente de carga.

Antes del go-live de una entrega grande

Repetir la corrida desde otro host (no el mismo que corre el servidor), para que el ida y vuelta del cliente deje de compartir recursos con BeneficiosCenter y la lectura de /actuator/prometheus quede como confirmación independiente.

Corpus del simulador de gateway (AC-41)¶

Relacionado pero distinto de la prueba de carga: valida corrección funcional contra datos reales, no throughput.

python tools/gateway-sim/gateway_sim.py --base-url http://localhost:8080 --api-key <clave-gateway> \
    --corpus tools/gateway-sim/corpus/sample.jsonl

Ver el detalle en Simulador del gateway.

Dónde sigue¶

Las métricas expuestas por Actuator y cómo leerlas, en Despliegue.
El invariante que esta prueba verifica, en Invariantes.