एक वेब पेज किंवा 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
```

## प्रथम मोजा: वेळ कोठे आहे?

ब्राउজर **नेटवर्क/परफॉर्मेन्स** टॅब आणि सर्व्हर **टाइमिंग** वापरून एकूण विभाजित करा. एक उपयोगी विभाजन:

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

**सरासरी नव्हे, टक्केवारी** पहा: **p50** (सामान्य वापरकर्ता) विरुद्ध **p99** (सर्वात वाईट परिस्थिती). जलद p50 सह हळू p99 अधूनमधून समस्या दर्शवितो — लॉक प्रतिद्वंद्विता, कोल्ड कॅश, हळू DB प्रतिकृती, किंवा GC थांबणे — एकसमान समस्या नव्हे.

## हळू स्पॅन ट्रेस करा

APM साधने (ट्रेस) विनंती अंदर वेळ कोठे जाते हे दाखवतात:

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

ट्रेस अपराधी कॉलकडे सरळ दर्शवितो. त्यानंतर **अलीकडील बदल** तपासा — एक deploy, गमावलेला अनुक्रमणिका, किंवा 10x डेटा वृद्धी बहुधा अचानक प्रतिगमन समजावते.

## हे महत्वाचे का आहे

अनुमान लगवून चुकीच्या स्तरावर ऑप्टिमाइज करण्यासाठी तास वाया करते. प्रथम मोजणे, हळू स्पॅन ट्रेस करणे, आणि **p50 विरुद्ध p99** पाहणे एक अस्पष्ट "हे हळू आहे" विशिष्ट, निश्चित करण्यायोग्य कारणात बदलते — आणि पुनः मोजणे हे सिद्ध करते की निराकरण खरेतर कार्य केले.