ვებ-გვერდი ან API ნელი — როგორ იპოვნებთ მიზეზს?

Question

Accepted Answer

**არ ვიცნობოთ — ჯერ გავზომოთ.** ნელობა შეიძლება იყოს კლიენტიდან, ქსელიდან, სერვერიდან ან ბაზიდან. მეთოდური მიდგომა იპოვის *სად* მიდის დრო, შემდეგ კი აფიქსირებს **ყველაზე დიდ წვლილს** ნაცრის მაგივრად ოპტიმიზაციის.

## მეთოდური თანმიმდევრობა

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

## ჯერ გავზომოთ: სად არის დრო?

გამოიყენეთ ბრაუზერის **Network/Performance** Tab და სერვერის **timing** ჯამური დაშლის. სასარგებლო დაშლა:

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

დააკვირდით **პერცენტილებს, არა საშუალოებს**: **p50** (ტიპური მომხმარებელი) vs **p99** (ყველაზე ცუდი შემთხვევა). სწრაფი p50 ნელი p99-თან ხელმძღვანელი მოუწოდებს ოკაზიონალური პრობლემებზე — lock contention, ცივი caches, ნელი DB რეპლიკა, ან GC pauses — არა ერთიანი პრობლემა.

## მიჰყევით ნელ span-ს

APM ხელსაწყოები (traces) ზუსტად აჩვენებენ სად მიდის დრო request-ის შიგნით:

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

Trace აკეთებს პირდაპირ მეცნიერულ call-ს. შემდეგ შეამოწმეთ **ბოლოს ცვლილებები** — deploy, დაკარგული index, ან 10x მონაცემთა ზრდა ხშირად განმარტავს მოულოდნელი რეგრესია.

## რატომ აქვს მნიშვნელობა

ვიცნობა დაკარგავს საათებს ვიცნობოთ ცუდი ფენის ოპტიმიზაციისას. პირველი გაზომვა, ნელი span-ის trace, და **p50 vs p99** დათვალიერება აქცევს ბუნდოვან "it's slow"-ს კონკრეტული, მოსახსნელი მიზეზად — და re-measuring ამტკიცებს fix ნამდვილად შემუშავდა.