# Informe de ejecución — 2026-07-13

Perfil: `shared8g` · Host: `ubuntu` (ASUS X441UAK, Ubuntu 24.04, i5-7200U, 8 GiB) · Gateway: `http://127.0.0.1:8189`

## Baseline

| Check | Resultado |
|-------|-----------|
| RAM | 4.4 GiB usados / 3.3 GiB disponibles / **swap 2.1 GiB** |
| IPS containers | healthy (api, bot, extraction, workers, count, cleaning, db, redis) |
| `/health/live` | ok · ~11 ms |
| `/health` | ok (4 servicios) · ~194 ms |
| Vecino pesado | mlflow-server ~1.84 GiB |

## Resultados

| ID | Resultado | Notas |
|----|-----------|-------|
| Smoke | **PASS** | Stack IPS OK |
| Unitarias agent | **PASS** | 19/19 en 3.21s |
| Unitarias API store | **PASS** | 7/7 en 1.45s |
| Unitarias count-api | **PASS** | 3/3 pipeline (Ubuntu + leptonica-dev) |
| ST-GW-01 | **PASS** | 6884 req · fail 0% · p95=40.85 ms |
| ST-BOT-01 #1 | **PARCIAL** | 100% HTTP 200 · p95=2.28 s · max=23 s (FAIL latencia) |
| ST-BOT-01 #2 | **PASS** | 100% HTTP 200 · p95=85.55 ms · max=98 ms |

## Capacidad 100k/mes

- Host actual compartido: **NO** (pipeline completo).
- Infra dedicada: **SÍ condicional** (ver informe PDF).

## Conclusión

Gateway y heartbeats de bot-descarga cumplen SLO del perfil `shared8g` en condiciones razonables. El fallo de latencia de BOT-01 #1 se atribuye a contención del host (swap + MLflow), no a error funcional de la API.

## Pendiente

- En Ubuntu: `go test ./internal/pipeline/ -v` y `go test ./internal/pipeline/ -run Timing -v`
- HTTP: `bash docs/plan_pruebas/scripts/measure_count_latency.sh`
- ST-BOT-03, ST-COUNT-01, E2E Imaging