shinkan-jinkendo/scripts/load/README.md

35 lines
1.3 KiB
Markdown
Raw Normal View History

# k6 – Health-Baseline (Phase 0)
Parallele GETs auf `/health` – **ohne** Auth, geeignet für Dev/Prod hinter dem gleichen Proxy wie die App.
**CI / Deploy:** In **`.gitea/workflows/test.yml`** eigener Job **`k6-health-baseline`** (nur Checkout + /health-Wartezeit + k6). **Playwright** läuft parallel/im selben Workflow im Job **`playwright-tests`** — ohne k6. Gleiche `BASE_URL`-Logik (Dev oder Prod nach `workflow_run`).
## Voraussetzung
[k6 installieren](https://k6.io/docs/getting-started/installation/).
## Aufruf Beispiel
```bash
# Windows PowerShell
$env:BASE_URL="https://dev.shinkan.jinkendo.de"
k6 run scripts/load/k6-health-baseline.js
```
```bash
# Linux / macOS
BASE_URL=https://dev.shinkan.jinkendo.de k6 run scripts/load/k6-health-baseline.js
```
**Architektur:** Der Workflow lädt **linux-amd64** oder **linux-arm64** je nach `uname -m` (z. B. Gitea-Runner auf Raspberry Pi 5).
## Auswertung
In der k6-Zusammenfassung `http_req_duration` → **p(95)** in [BASELINE_SNAPSHOT.md](../../docs/architecture/BASELINE_SNAPSHOT.md) eintragen.
Schwellwerte sind bewusst locker (`p95 < 3s`); bei Fehlschlag Proxy, Netz oder Backend prüfen.
## EXPLAIN (Phase 2)
Datei **`explain-readpaths.sql`**: Vorlagen für `EXPLAIN (ANALYZE, BUFFERS)` auf der Ziel-DB (manuell, nicht CI).