Nu ghici — măsoară mai întâi. Lentoarea poate veni de la client, rețea, server sau bază de date. O abordare metodică găsește unde se duce timpul, apoi fixează cel mai mare contributor în loc să optimizezi aleatoriu.
Nu ghici — măsoară mai întâi. Lentoarea poate veni de la client, rețea, server sau bază de date. O abordare metodică găsește unde se duce timpul, apoi fixează cel mai mare contributor în loc să optimizezi aleatoriu.
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
Folosește fila Network/Performance a browserului și timing serverului pentru a împărți totalul. O împărțire utilă:
Total 1200ms =
DNS/connect 20ms
server TTFB 900ms ← the bottleneck is server-side
download 80ms
client render 200ms
Uită-te la percentile, nu medii: p50 (utilizator tipic) vs p99 (cel mai rău caz). Un p50 rapid cu un p99 lent indică probleme ocazionale — lock contention, cache-uri reci, o replică de BD lentă, sau GC pauses — nu o problemă uniformă.
Instrumentele APM (traces) arată exact unde se duce timpul în cadrul unei cereri:
GET /orders 950ms
├─ auth check 10ms
├─ SELECT orders 30ms
└─ loop: SELECT user per order 900ms ← N+1 query, the real cause
Urmele indică direct spre apelul vinovat. Apoi verifică schimbări recente — o implementare, un index lipsă, sau o creștere de date de 10x explică adesea o regresiune bruscă.
Ghicitul risipește ore optimizând stratul greșit. Măsurarea mai întâi, urmărirea span-ului lent și privirea la p50 vs p99 transformă un vag "este lent" în o cauză specifică, reparabilă — și remăsurarea dovedește că reparația a funcționat de fapt.