डेटाबेस बदलने से पहले महँगे अनुरोध को खोजें
एक उपयोगकर्ता क्रिया से शुरू करें: केटेगरी लोड, आर्टिकल सर्च, कार्ट में जोड़ना, या ऑर्डर सबमिशन। उसके रूट, क्वेरी गणना, डेटाबेस अवधि, लौटाए गए पंक्तियाँ, और अनुरोध अवधि को कैप्चर करें। एक धीमा पेज एप्लिकेशन कोड या किसी अन्य निर्भरता पर भी इंतज़ार कर सकता है, इसलिए केवल पेज-लोड समय से निदान न करें।
एक क्वेरी प्लान तालिकाओं, इंडेक्स, जॉइन, सॉर्ट और एग्रीगेट्स के माध्यम से डेटाबेस का रूट है। PostgreSQL में, EXPLAIN वह मार्ग दिखाता है। EXPLAIN ANALYZE स्टेटमेंट चलाता है और वास्तविक पंक्तियाँ व टाइमिंग रिपोर्ट करता है, इसलिए एक सुरक्षित प्रतिनिधि क्वेरी का उपयोग करें। अनुमान और वास्तविक पंक्तियों के बीच बड़ा अंतर सांख्यिकियों या कंडीशनों की जांच का कारण है, न कि स्वचालित रूप से इंडेक्स मांग का।
उम्मीदवार क्वेरी को एक रूट और परिणाम से बाँधें, ताकि सिर्फ डैशबोर्ड रिपोर्ट धीमे चेकआउट से ऊपर न चले जाए।
बदलाव से पहले के टाइमिंग्स और तुलनीय ट्रैफ़िक रिकॉर्ड करें बिना ग्राहक पहचान, टोकन, या कार्ड-संबंधी मान लॉग किए।
वास्तव में उपयोग किए जाने वाले एक्सेस पाथ के लिए इंडेक्स डिज़ाइन करें
इंडेक्स एक मेंटेन किए जाने वाला स्ट्रक्चर है जो पंक्तियाँ खोजने या उन्हें क्रम में लौटाने में मदद कर सकता है; यह कोई सार्वभौमिक गति स्विच नहीं है। किसी महत्वपूर्ण क्वेरी के फ़िल्टर, जॉइन कीज़, और सॉर्ट ऑर्डर से शुरू करें, फिर प्रस्तावित इंडेक्स को प्लान में सत्यापित करें। PostgreSQL दस्तावेज़ बताते हैं कि एक मैचिंग B-tree इंडेक्स ORDER BY को अलग सॉर्ट के बिना संतोषजनक कर सकता है, खासकर छोटे LIMIT के साथ।
इंडेक्स स्टोरेज और लिखने के कार्य जोड़ते हैं क्योंकि inserts, updates, और deletes उन्हें मेंटेन करते हैं। किसी क्वेरी के लिए तालिका का बड़ा भाग आवश्यक होने पर क्रमिक स्कैन (sequential scan) और स्पष्ट सॉर्ट तेज़ हो सकते हैं। प्रोडक्शन जैसी डेटा पर टेस्ट करें और केवल तब इंडेक्स रखें जब लाभ इसकी लागत को जस्टिफाई करे।
क्वेरी के वास्तविक फ़िल्टर और ORDER BY का उपयोग करें, उस स्थिति में भी डिटरमिनिस्टिक टाई-ब्रेकर शामिल करें जहाँ इंटरफ़ेस को स्थिर क्रम चाहिए।
देखें कि इंडेक्स इस्तेमाल हो रहा है और लिखते समय इसकी लागत क्या है; डेटा और ट्रैफ़िक बदलने पर पुनः-जाँच करें।
पेजिनेशन को स्थिर और किफायती बनाएं
पेज-नंबर पेजिनेशन आमतौर पर LIMIT के साथ OFFSET का उपयोग करता है। हमेशा एक अनुमानित ORDER BY लागू करें। PostgreSQL चेतावनी देता है कि बिना ORDER BY के LIMIT अनिश्चित उपसमूह लौटा सकता है; अलग LIMIT या OFFSET मान असंगत उपसमूह दे सकते हैं क्योंकि ऑप्टिमाइज़र अलग प्लान चुन सकता है।
बड़े offsets की जाँच आवश्यक है क्योंकि स्किप की गई पंक्तियों की गणना अभी भी करनी पड़ती है। गहरे कैटलॉग, ऑर्डर-इतिहास, या आर्काइव ब्राउज़िंग के लिए, cursor या keyset पेजिनेशन पर विचार करें: अंतिम देखे गए स्थिर सॉर्ट मान और यूनिक टाई-ब्रेकर के बाद की पंक्तियाँ अनुरोध करें। इंटरफ़ेस बदलने से पहले नए या हटे हुए रिकॉर्ड कैसे दिखेंगे, इसे परिभाषित करें।
असीमित रिज़ल्ट के बजाय सबसे छोटे उपयोगी पृष्ठ को लौटाएं।
निर्णय लें कि क्या इंटरफ़ेस को वास्तव में हर अनुरोध पर सटीक कुल चाहिए।
गलत उत्तर दिए बिना रीड काम को कैश करें
कैशिंग किसी पहले के रिज़ल्ट का पुन: उपयोग है बजाय इसके कि उसे डेटाबेस से फिर से बनाना पड़े। सार्वजनिक, बार-बार उपयोग होने वाले पेज और वर्शन किये गए एसेट्स के लिए HTTP लेयर से शुरू करें, क्योंकि कैश हिट एप्लिकेशन और डेटाबेस का काम बचा सकता है। web.dev वर्शन किए गए URLs के लिए लंबे समय तक कैशिंग की सलाह देता है; URL बदलना व्यावहारिक इनवैलिडेशन मैकेनिज़्म है।
कैश नीति एक सटीकता (correctness) निर्णय है। एक साझा कैश एक ही रिस्पॉन्स को कई उपयोगकर्ताओं के बीच पुन: उपयोग कर सकता है, इसलिए अकाउंट, कार्ट, मूल्य, या ऑथORIZATION-विशिष्ट आउटपुट को तब तक साझा न करें जब तक कि वह उस दायरे के लिए डिज़ाइन और टेस्ट न किया गया हो। Cache-Control private ब्राउज़र कैश तक पुन: उपयोग को सीमित करता है, जबकि no-store निर्देश देता है कि कैश इसे बनाए न रखें।
पब्लिक कैटलॉग या आर्टिकल आउटपुट को सेशन-विशिष्ट, स्थान-विशिष्ट, और अनुमति-संवेदनशील आउटपुट से अलग करें।
परिभाषित करें कि कौन किसके लिए स्टेल वैल्यू देख सकता है, कितनी देर के लिए, और इनवैलिडेशन या रीवालिडेशन का रास्ता क्या है।
सिर्फ़ छत बढ़ाने के बजाय कनेक्शन क्षमता की रक्षा करें
एक कनेक्शन डेटाबेस के लिए एक लाइव क्लाइंट सेशन है। वर्कर, क्रोन जॉब, प्रीव्यू, या रिट्राईज़ स्लॉट समाप्त कर सकते हैं भले ही व्यक्तिगत क्वेरियाँ स्वीकार्य दिखें। PostgreSQL का max_connections समवर्ती कनेक्शनों को नियंत्रित करता है, सर्वर स्टार्ट पर सेट होता है, और उच्च मान अधिक संसाधन (शेयर्ड मेमोरी सहित) आवंटित करता है। बिना वर्कलोड मॉडल के इसे बढ़ाने से विफलता का स्थानांतरण हो सकता है।
वेब वर्कर्स, बैकग्राउंड जॉब्स, एडमिनिस्ट्रेशन और रेप्लिकाज़ के लिए एक बजट सेट करें। जहाँ फिट हो bounded pooling का उपयोग करें, रिकवरी के लिए हेडरूम सुरक्षित रखें, और टाइमआउट लागू करें ताकि फंसा हुआ काम अनिश्चित काल तक प्रतीक्षा न करे। सुरक्षित संख्याएँ इंजन, मेमोरी, क्वेरी मिक्स, और प्रदाता सीमाओं पर निर्भर करती हैं; ऑपरेटर के साथ इन्हें पुष्टि करें।
वेब प्रोसेस, कतारें, शेड्यूल किए गए टास्क, माइग्रेशन, रिपोर्टिंग टूल, और डिप्लॉयमेंट जॉब्स शामिल करें।
कनकरेंसी को कैप करें और बैकऑफ़ का उपयोग करें ताकि एक फॉल्ट कनेक्शन मांग को गुणा न करे।
संदर्भ और निजता नियंत्रण के साथ क्वेरी लागत का अवलोकन करें
डेटाबेस काम को एक धीमे सिंगल सैंपल से नहीं बल्कि कुल प्रभाव के अनुसार रैंक करें। कुछ-कुछ सैकेंड धीमी क्वेरी जिसे हजारों बार कॉल किया जाता है, एक दुर्लभ रिपोर्ट से अधिक मायने रख सकती है। PostgreSQL का pg_stat_statements प्लैनिंग और निष्पादन डेटा को समेकित करता है जिनमें calls, कुल और औसत निष्पादन समय, पंक्तियाँ, और बफ़र गतिविधि शामिल हैं। इसे जोड़ने या हटाने के लिए सर्वर कॉन्फ़िगरेशन और रीस्टार्ट की ज़रूरत होती है; प्लैनिंग ट्रैकिंग ओवरहेड जोड़ सकती है।
क्वेरी समूहों को रूट, रिलीज़ वर्शन, और समय विंडो से जोड़ें। OpenTelemetry सामान्यतः क्वेरी टेक्स्ट को डिफ़ॉल्ट रूप से तभी इकट्ठा करने की सलाह देता है जब लिटरल्स को सैनिटाइज़ कर के बदला गया हो, और ग्रुपिंग के लिए कम-कार्डिनैलिटी क्वेरी समरी का उपयोग करने की सलाह देता है। यह मालिकों को ट्रेंड दिखाने में मदद करता है बिना ग्राहक डेटा एक्सपोर्ट किए या हर वैल्यू के लिए एक लेबल बनाए।
अवधि, कुल समय, कॉल्स, त्रुटियाँ, कनेक्शन्स, और पंक्तियाँ देखें; प्रत्येक एक अलग विफलता मोड उजागर करता है।
पैरामीटराइज़्ड क्वेरीज़ का उपयोग करें और ट्रेस या लॉग एप्लिकेशन से बाहर जाने से पहले लिटरल्स हटाए गए हों, यह सत्यापित करें।
डेटाबेस बदलावों को उलटने योग्य विश्वसनीयता कार्य के रूप में भेजें
एक इंडेक्स, रीराइट, कैश नीति, पूल सेटिंग, या स्कीमा परिवर्तन को एक प्रोडक्शन परिवर्तन की तरह ट्रीट करें जिसमें एक ओनर, सफलता की माप और रोलबैक निर्णय हो। प्रतिनिधि पर्यावरण में सत्यापित करें, सीमित स्लाइस पर रिलीज़ करें, और प्रभावित यात्रा को मॉनिटर करें। तेज़ होना सफलता नहीं है यदि परिवर्तन गलत, गायब, डुप्लिकेट, या स्टेल डेटा लौटाता है।
स्कीमा परिवर्तन सावधानी माँगते हैं क्योंकि एप्लिकेशन वर्शन ओवरलैप कर सकते हैं। Google Cloud निर्देश एक कंपैटिबिलिटी सिक्वेंस का वर्णन करते हैं: एक ऐसा एप्लिकेशन रिलीज़ करें जो पुराने और नए स्कीमा दोनों को संभाले, स्कीमा बदलें, फिर उस फीचर को रिलीज़ करें जो इसका उपयोग करता है। यह एप्लिकेशन रोलबैक मार्ग को सुरक्षित रखता है। लॉकिंग और ऑनलाइन-चेंज व्यवहार इंजन और मैनेज्ड सर्विस के अनुसार भिन्न होता है; उच्च-वॉल्यूम या पेमेंट-संबंधित सिस्टम के लिए योग्य समीक्षा प्राप्त करें।
रूट, प्रदर्शन और सटीकता संकेतों, और उस थ्रेशोल्ड का नाम रखें जो रोलआउट को रोकता है।
कंट्रोल किए गए स्लाइस में प्रदर्शन और सटीकता सत्यापित करें इससे पहले कि आप चौड़ाई बढ़ाएं; एक घटना के अलावा लौटने का रास्ता अभ्यास में रखें।