Spletna stran ali API je počasna — kako najdeš vzrok?

Question

Accepted Answer

**Ne ugibaj — najprej izmeri.** Počasnost lahko izvira iz odjemalca, omrežja, strežnika ali baze podatkov. Sistematičen pristop najde *kje* se čas porabi, nato pa popravi **največji prispevnik** namesto naključnega optimiziranja.

## Sistematično zaporedje

```text
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
```

## Izmeri najprej: kje je čas?

Uporabi zavihek **Network/Performance** v brskalniku in **timing** na strežniku za razdelitev skupne količine. Koristen razčlen:

```text
Total 1200ms =
  DNS/connect      20ms
  server TTFB     900ms   ← the bottleneck is server-side
  download         80ms
  client render   200ms
```

Poglej **percentile, ne povprečja**: **p50** (tipičan uporabnik) vs **p99** (najslabši primer). Hiter p50 s počasnim p99 kaže na občasne težave — spora zapora, hladne cache-e, počasno DB repliko ali GC pauzacije — ne na enakomerno težavo.

## Sledi počasnem razponu

APM orodja (sledi) pokažejo natanko, kje se čas porabi znotraj zahteve:

```text
GET /orders                       950ms
  ├─ auth check                    10ms
  ├─ SELECT orders                 30ms
  └─ loop: SELECT user per order  900ms   ← N+1 query, the real cause
```

Slad kaže direktno na klical, ki povzroča težavo. Nato provjeri **nedavne spremembe** — razdelitev, manjkajoči indeks ali 10-kratna rast podatkov pogosto razlagajo nenadne padce delovanja.

## Zakaj je to pomembno

Ugibanje zapravi ure optimiziranja napačne plasti. Merjenje najprej, sledenje počasnega razpona in pregled **p50 vs p99** spremeni nejasno "to je počasno" v specifičen, popravljen vzrok — in ponovno merjenje dokaže, da je popravka res delovala.