जो endpoint पहले 80 मिलीसेकंड लेता था वह अब प्रोडक्शन में चार सेकंड लेता है। वजह कैसे ढूंढेंगे?

अंदाज़े से पहले नापिए। तय कीजिए कि यह सबके लिए धीमा है या एक ही account के लिए, फिर कोई trace पढ़कर देखिए कि समय असल में कहां जा रहा है: एप्लिकेशन के कोड में, डेटाबेस में, या किसी बाहर जाती कॉल में। ज़्यादातर मामलों में डेटाबेस होता है, तो slow query log निकालिए और संदिग्ध query पर EXPLAIN ANALYZE चलाइए। साथ ही देखिए कि क्या बदला, क्योंकि कोई deploy, डेटा की मात्रा का कोई पड़ाव, या ऐसा cache जिसने hit करना बंद कर दिया, ज़्यादातर गिरावटें इन्हीं से समझ आती हैं।

पहले मुझे समस्या की शक्ल चाहिए। यह हर request है या निन्यानवेवां percentile, एक tenant है या सब, और ठीक कब शुरू हुई। वह timestamp अक्सर आधा मामला अपने आप सुलझा देता है, क्योंकि वह किसी deploy, migration या config बदलाव से जा मिलता है। फिर मैं किसी धीमी request का trace निकालकर उसका waterfall देखता हूं, क्योंकि कौन सी परत धीमी है यह अंदाज़ा लगाना सबसे ज़्यादा समय बर्बाद करता है। अगर डेटाबेस है, तो मैं slow query log देखता हूं और EXPLAIN ANALYZE चलाता हूं, और आम जवाब होते हैं table बढ़ने के बाद plan का पलट जाना, नए filter वाले column पर index का न होना, या कोई N plus one जो अब चोट देता है क्योंकि accounts में rows बढ़ गई हैं। अगर कोई बाहर जाती कॉल है, तो मैं देखता हूं कि वह dependency खराब चल रही है या नहीं और हमारे पास timeout है भी या नहीं, क्योंकि timeout न होना उनके बुरे दिन को हमारा बना देता है। इस बीच अगर यूज़र को तकलीफ हो रही है तो मैं पहले राहत देता हूं: rollback, कोई छोटा cache, या महंगा रास्ता बंद, और फिर बिना दबाव के जांच पूरी करता हूं।