अनुमान न लगाएँ — पहले मापें। धीमापन client, network, server, या database से आ सकता है। एक व्यवस्थित दृष्टिकोण पहले खोजता है कि समय कहाँ जा रहा है, फिर बेतरतीब optimize करने के बजाय सबसे बड़े योगदानकर्ता को ठीक करता है।
अनुमान न लगाएँ — पहले मापें। धीमापन client, network, server, या database से आ सकता है। एक व्यवस्थित दृष्टिकोण पहले खोजता है कि समय कहाँ जा रहा है, फिर बेतरतीब optimize करने के बजाय सबसे बड़े योगदानकर्ता को ठीक करता है।
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
कुल को विभाजित करने के लिए browser के Network/Performance tab और server timing का उपयोग करें। एक उपयोगी विभाजन:
Total 1200ms =
DNS/connect 20ms
server TTFB 900ms ← the bottleneck is server-side
download 80ms
client render 200ms
percentiles देखें, averages नहीं: p50 (सामान्य user) बनाम p99 (worst case)। तेज़ p50 के साथ धीमा p99 कभी-कभार आने वाली समस्याओं की ओर इशारा करता है — lock contention, ठंडे caches, एक धीमा DB replica, या GC pauses — न कि किसी एकसमान समस्या की।
APM tools (traces) ठीक-ठीक दिखाते हैं कि किसी request के भीतर समय कहाँ जाता है:
GET /orders 950ms
├─ auth check 10ms
├─ SELECT orders 30ms
└─ loop: SELECT user per order 900ms ← N+1 query, the real cause
trace सीधे दोषी call की ओर इशारा करता है। फिर हाल के changes जाँचें — एक deploy, एक गायब index, या 10x data growth अक्सर अचानक आए regression को समझा देता है।
अनुमान लगाने से गलत layer को optimize करने में घंटों बर्बाद होते हैं। पहले मापना, slow span को trace करना, और p50 बनाम p99 देखना एक अस्पष्ट "यह धीमा है" को एक विशिष्ट, ठीक किए जा सकने वाले कारण में बदल देता है — और फिर से मापना यह साबित करता है कि fix ने वास्तव में काम किया।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें