વેબ પેજ અથવા 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
```

## પહેલા માપો: સમય ક્યાં જાય છે?

બ્રાઉઝર **નેટવર્ક/પરફોર્મન્સ** ટ્યાબ અને સર્વર **timing** વાપરો કુલને વિભાજિત કરવા માટે. એક ઉપયોગી વિભાજન:

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

**પર્સેન્ટાઇલ્સ જુઓ, સરેરાશ નહીં**: **p50** (સામાન્ય વપરાશકર્તા) વિરુદ્ધ **p99** (સૌથી ખરાબ સ્થિતિ). ઝડપી p50 સાથે ધીમું p99 અનુભવતા હોય તો તે પાસે કયારેક કયારેક સમસ્યાઓ નિર્દેશ કરે છે — તાળા સમસ્યા, ઠંડા કેશ, ધીમું ડીબી પ્રતિલિપિ, અથવા GC વિરામ — એક સમાન સમસ્યા નહીં.

## ધીમા સ્પેનને ટ્રેસ કરો

APM સાધનો (traces) બરાબર દર્શાવે છે જ્યાં સમય એક વિનંતી ની અંદર જાય છે:

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

ટ્રેસ સીધું અપરાધી કલને નિર્દેશ કરે છે. પછી **તાજેતરના પરિવર્તનો** તપાસો — એક deploy, એક ખોવાયેલ index, અથવા 10x ડેટા વૃદ્ધि ઘણીવાર અચાનક રીગ્રેશન સમજાવે છે.

## તે શા માટે મહત્વપૂર્ણ છે

અનુમાન કરવું ગલત સ્તર ઓપ્ટિમાઇઝ કરવામાં કલાક બરબાદ કરે છે. પહેલા માપવું, ધીમા સ્પેનને ટ્રેસ કરવું, અને **p50 બટ p99** જોવું એક અસ્પષ્ટ "તે ધીમું છે" ને એક ચોક્કસ, સુધારણીય કારણમાં ફેરવે છે — અને ફરીથી માપવું સાબિત કરે છે કે સુધાર ખરેખર કામ કર્યું.