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 for migreringsplan.