# Load Test Results — 2026-02-18

# Load Test Results — Drop Staging

**Dato:** 2026-02-18
**Verktøy:** k6 v1.6.1
**Mål:** https://drop-staging.fly.dev
**Server:** Fly.io shared-cpu-1x (256MB RAM, 1 delt CPU, Stockholm)

---

## Testoppsett

To scenarier kjørt samtidig:

### Scenario 1: Public Stress (helse + valutakurser)
- Ramper fra 0 → 200 samtidige brukere over 2m40s
- Ingen autentisering, tester rå serverkapasitet

### Scenario 2: Autentisert brukerflyt
- Ramper fra 0 → 30 samtidige brukere
- Login → Dashboard → Transaksjoner → Mottakere → Profil
- JWT token gjenbrukt per VU

---

## Resultater

| Samtidige brukere | Median latens | p95 latens | Feilrate | Status |
|:-:|:-:|:-:|:-:|:-:|
| **1-10** | **74ms** | ~90ms | 0% | Fungerer utmerket |
| **25-50** | ~500ms | ~3s | ~5% | Degradering starter |
| **75-100** | ~2-3s | ~6s | ~30% | Alvorlige problemer |
| **150-200** | 3s+ | **27s+** | **47%** | Praktisk talt nede |

### Detaljerte tall (k6 output)

**Public endpoints:**
- `health_duration`: avg=1134ms, min=54ms, med=74ms, max=44s, p90=3.5s, p95=6.2s
- `rates_duration`: avg=1077ms, min=55ms, med=74ms, max=45s, p90=3.3s, p95=6.4s
- `/api/rates` feilet i 95% av forespørslene ved høy last
- `/api/health` holdt (alltid 200)

**Autentiserte endpoints:**
- `http_req_duration (auth_flow)`: med=3.26s, p90=14.8s, p95=27.6s
- Dashboard og transaksjonshistorikk hardest rammet

**Totalt:**
- 12,841 HTTP-forespørsler over 2m53s
- 74 req/s gjennomsnitt
- 48.4% av alle forespørsler feilet

---

## Breaking Point

**~25-30 samtidige brukere**

Etter dette eksploderer responstidene og endepunkter begynner å feile.

---

## Flaskehalser identifisert

### 1. Maskinressurser (KRITISK)
- shared-cpu-1x = 256MB RAM, 1 delt CPU
- Bokstavelig talt den minste Fly.io-planen
- CPU-metning ved ~50 samtidige forespørsler

### 2. SQLite single-writer (HØY)
- SQLite WAL-modus hjelper med samtidige lesinger
- Men ALLE skrivinger (rate_limits, sessions) er serialiserte
- Under last: skrivelås blokkerer lesinger

### 3. Null caching (MEDIUM)
- Ingen Redis eller in-memory cache
- Valutakurser hentes fra DB på hver forespørsel
- Brukersesjoner valideres mot DB hver gang

### 4. bcrypt 12 rounds (MEDIUM)
- Passord-hashing koster ~300ms CPU per innlogging
- Saturerer delt CPU raskt under innloggingsbølger

### 5. Enkeltinstans (MEDIUM)
- Ingen horisontal skalering
- auto_stop_machines = stop → kaldstarter (3.8s første forespørsel)
- min_machines_running = 0 → ingen alltid-på instanser

---

## Oppgraderingsplan

| Oppgradering | Effekt | Kostnad |
|-------------|--------|--------|
| Fly.io performance-1x (2GB RAM, 1 dedikert CPU) | ~3x kapasitet (~75 brukere) | ~$30/mnd |
| + PostgreSQL i stedet for SQLite | Samtidige skrivinger, connection pooling | ~$15/mnd |
| + Redis cache (kurser, sesjoner) | 10x raskere på lese-endepunkter | ~$10/mnd |
| + 2 instanser (auto-scale) | ~150+ brukere | ~$60/mnd totalt |
| **Full produksjonsoppsett** | **~500+ brukere** | **~$100/mnd** |

---

## Konklusjon

For MVP/demo med SpareBank 1: Nåværende oppsett holder 10-15 samtidige brukere — tilstrekkelig for demo. For pilot med ekte brukere trengs minimum PostgreSQL + større maskin.

Se også: [Cloud Migration Strategy — GCP → Azure](../cloud-migration-strategy-gcp-azure) for migreringsplan.