# Lasttest – referensvärden

Skript: `scripts/loadtest.mjs` (autocannon, 25 samtidiga anslutningar, 10 s per scenario).
Kör mot valfri miljö: `API_BASE_URL=https://… node scripts/loadtest.mjs`
Trösklar: p99 < 500 ms, 0 fel, > 100 req/s på receptlistan. UNDERKÄND ger exitkod 1 (CI-vänligt).

## Senaste körning (dev-container, 1 process, lokal Postgres)

| Scenario                                               | req/s | p50    | p99    | fel |
| ------------------------------------------------------ | ----- | ------ | ------ | --- |
| healthz (baslinje)                                     | 12040 | 1 ms   | 6 ms   | 0   |
| GET /v1/recipes (lista + i18n-upplösning)              | 754   | 31 ms  | 74 ms  | 0   |
| GET /v1/recommendations/what-to-eat (tyngsta läsvägen) | 135   | 173 ms | 290 ms | 0   |

Kommentar: healthz visar ren Fastify-overhead. Receptlistan inkluderar
i18n-titelupplösning mot översättningstabellen. Rekommendationsvägen är
medvetet tyngst (lager + FEFO + motor + förklaringar) – ~126 req/s på en
utvecklingscontainer motsvarar med god marginal förväntad lanseringstrafik;
skala horisontellt (fler API-containrar) före databasen.

## Vid produktionssättning

1. Kör mot staging bakom TLS – förvänta ~10–20 % lägre värden (TLS + nät).
2. Kör om efter varje kapacitetspåverkande ändring (nya index, tunga endpoints).
3. Rate limit: produktion har 300 req/min/IP – lasttest kräver RATE_LIMIT_MAX-överstyrning.