Gissa inte — mät först. Långsamhet kan komma från klienten, nätverket, servern eller databasen. En metodisk metod hittar var tiden går, och åtgärdar sedan största bidragsgivaren istället för att optimera slumpmässigt.
Gissa inte — mät först. Långsamhet kan komma från klienten, nätverket, servern eller databasen. En metodisk metod hittar var tiden går, och åtgärdar sedan största bidragsgivaren istället för att optimera slumpmässigt.
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
Använd fliken Network/Performance i webbläsaren och server timing för att dela upp det totala. En användbar uppdelning:
Total 1200ms =
DNS/connect 20ms
server TTFB 900ms ← the bottleneck is server-side
download 80ms
client render 200ms
Titta på percentiler, inte medelvärden: p50 (typisk användare) vs p99 (värsta fall). En snabb p50 med en långsam p99 pekar på sporadiska problem — låsningskontention, kalla cacheminnen, en långsam DB-replik eller GC-pauser — inte ett enhetligt problem.
APM-verktyg (spår) visar exakt var tiden går inom en förfrågan:
GET /orders 950ms
├─ auth check 10ms
├─ SELECT orders 30ms
└─ loop: SELECT user per order 900ms ← N+1 query, the real cause
Spåret pekar direkt på det kränkande anropet. Kontrollera sedan senaste ändringar — en distribution, ett index som saknas eller 10x datavöxt förklarar ofta en plötslig regression.
Gissning slösar timmar på att optimera fel lager. Mätning först, spårning av det långsamma intervallet och titt på p50 vs p99 förvandlar ett vagt "det är långsamt" till en specifik, fixbar orsak — och omätning bevisar att fixningen faktiskt fungerade.