API-ის p99 latency არის 3წმ — როგორ დებაგავთ და აოპტიმიზირებთ მას?

Question

IT Interview Practice · Accepted Answer

p99 = **tail latency**: ყველაზე ნელი 1% მოთხოვნებს ჭირდება 3წმ. პირველი სვლა არის **გაზომვა და დაშლა, და არა გამოცნობა**. შეადარეთ p50 vs p99 — თუ p50 სწრაფია, მაგრამ p99 არის 3წმ, path არ არის ერთგვაროვნად ნელი; რაღაც კბენს მხოლოდ *load-ის ქვეშ ან edge cases-ში* (pool saturation, GC pauses, N+1, cold cache, un-timed გარე გამოძახება).

**აზროვნების მოდელი:** p99 არის *ყველაზე გრძელი კასის რიგი*, და არა საშუალო ლოდინი — საშუალოს დაჩქარება არაფერს აკეთებს იმ მომხმარებლისთვის, რომელიც ბოლოში გაჭედა.

## პროცესი (საიდან სადამდე)
1. **გაზომეთ და დაშალეთ** — RED metrics (Rate, Errors, Duration) + distributed tracing; წაიკითხეთ p50/p95/p99. მათ შორის *სხვაობა* ყვება ამბავს.
2. **ლოკალიზეთ სტადია** — instrument-ი გაუკეთეთ ყოველ ნაბიჯს, რომ ნახოთ სად ხარჯავენ დროს ნელი მოთხოვნები; ნუ აოპტიმიზირებთ ვარაუდით.

```js
// გაზომე ყოველი სტადია, რომ ნახო სად გროვდება p99 (ნუ გამოიცნობ)
async function handler(req, res) {
  const t0 = process.hrtime.bigint();
  const mark = (label) =>
    req.log.info({ label, ms: Number(process.hrtime.bigint() - t0) / 1e6 });
  const user = await db.user.find(req.id);   mark('db.user');
  const courses = await loadCourses(user);   mark('loadCourses'); // საეჭვო
  res.json(courses);                         mark('total');
}
```

3. **ამოიცანით tail-ის საეჭვო** — ჩვეულებრივ *ლოდინი*, და არა გამოთვლა: connection-pool exhaustion, N+1 queries, un-timed გარე გამოძახებები, GC pauses, გამოტოვებული index, cold cache.

```js
// BEFORE: N+1 — N თანმიმდევრული round-trip, p99 იფეთქებს N-ის ზრდასთან ერთად
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// AFTER: შეკუმშე 1 query-მდე -> tail ეცემა (აღარ არის N თანმიმდევრული trip)
const courses = await db.course.findByUser(userId);
const lessons = await db.lesson.byCourseIds(courses.map((c) => c.id)); // ერთი IN(...)
const byCourse = Map.groupBy(lessons, (l) => l.courseId);
for (const c of courses) c.lessons = byCourse.get(c.id) ?? [];
```

აქ p50 (მცირე N) კარგად გამოიყურება, მაგრამ load-ის ქვეშ N იზრდება და pool საჯერდება, ამიტომ **p99 აფეთქდება**. გარე გამოძახებებისთვის ყოველთვის დააყენეთ **timeout + circuit breaker**, ისე რომ ერთმა ნელმა dependency-მ ვერ გადაათრიოს მთელი endpoint-ის p99.

4. **გაასწორეთ ერთი რამ → ხელახლა გაზომეთ p99 → გაიმეორეთ.** ერთი ცვლადი ერთდროულად, თორემ ვერ გაიგებთ რამ დაგეხმარათ.
5. **დააფიქსირეთ** — დააყენეთ **SLO** (მაგ. p99 < 300ms) + alert, ისე რომ ის არ დაბრუნდეს უკან.

## ინტერვიუს პრიზმა
ინტერვიუერი ამოწმებს *მეთოდურ* პროცესს, და არა იღბლიან გამოცნობას: აცალკევებთ თუ არა **tail-ს mean-ისგან**, ზომავთ თუ არა ცვლილებამდე, და უყურებთ თუ არა **queues/locks-ს (ლოდინი) CPU-მდე**. სუსტი პასუხი: „დაამატე caching / გაზარდე სერვერები." ძლიერი პასუხი: გაზომვა → ლოკალიზაცია tracing-ით → tail-ის კონკრეტული მიზეზის გასწორება → ვერიფიკაცია ციფრებით.

## პრინციპი
აოპტიმიზირეთ **tail (p99), და არა საშუალო**. „3წმ p99"-ის უმეტესობა მოდის *ლოდინიდან* (pool/queue/lock), და არა *გამოთვლიდან* — ამიტომ შეხედეთ queues-ს CPU-მდე.

პროცესი (საიდან სადამდე)

ინტერვიუს პრიზმა

პრინციპი

დაკავშირებული კითხვები