Gæt ikke — mål først. Langsomhed kan komme fra klienten, netværket, serveren eller databasen. En metodisk tilgang finder hvor tiden går hen, og fikserer derefter den største bidragyder i stedet for at optimere tilfældigt.
Gæt ikke — mål først. Langsomhed kan komme fra klienten, netværket, serveren eller databasen. En metodisk tilgang finder hvor tiden går hen, og fikserer derefter den største bidragyder i stedet for at optimere tilfældigt.
1. MEASURE → where is the time spent? client render, network, server, DB?
2. REPRODUCE → confirm it reliably (same endpoint, payload, user)
3. TRACE → use APM/distributed traces to find the slow span
4. CHECK RECENT CHANGES → deploys, config, traffic, data growth
5. ISOLATE → layer by layer, narrow to one component
6. FIX the biggest contributor → re-measure to confirm
Brug browserens Network/Performance fane og server timing til at opdele totalen. Et brugbart sammenbrud:
Total 1200ms =
DNS/connect 20ms
server TTFB 900ms ← the bottleneck is server-side
download 80ms
client render 200ms
Kig på percentiler, ikke gennemsnit: p50 (typisk bruger) mod p99 (værste tilfælde). Hurtigt p50 med langsomt p99 peger på lejlighedsvise problemer — låskontention, kolde cacher, en langsom DB-replika eller GC-pauser — ikke et ensartet problem.
APM-værktøjer (traces) viser præcis hvor tiden går inden for en anmodning:
GET /orders 950ms
├─ auth check 10ms
├─ SELECT orders 30ms
└─ loop: SELECT user per order 900ms ← N+1 query, the real cause
Sporet peger direkte på det problematiske opkald. Kontroller derefter nylige ændringer — en udrulning, et manglende indeks eller 10x datavækst forklarer ofte en pludselig regression.
Gætning spildsker timer på at optimere det forkerte lag. At måle først, spore det langsomme interval og se på p50 mod p99 forvandler et vagt "det er langsomt" til en specifik, fikserbar årsag — og omaling beviser at fikseringen faktisk virkede.