डेवलपर्स देखते हैं कि उनकी हाल ही में लॉन्च हुई ऐप जैसे ही कुछ हज़ार यूज़र्स “go” पर क्लिक करते हैं, थम जाती है, और यह सुस्ती (slowdown) शायद ही कभी कोड में कोई बग होती है – यह सर्वर के CPU और RAM के बीच जगह के लिए होने वाली लड़ाई है। यह बाधा (bottleneck) लंबे पेज लोड, टाइम-आउट, या सीधे क्रैश के रूप में दिखाई देती है, और यह यूज़र एक्सपीरियंस, रेवेन्यू और ब्रांड ट्रस्ट को नुकसान पहुँचाती है।

क्यों एक सर्वर जो लैब में ठीक से चला था, प्रोडक्शन में रुक सकता है

डेवलपमेंट के दौरान एक अकेला डेवलपर कुछ ही रिक्वेस्ट भेजता है, इसलिए सर्वर के रिसोर्सेज (resources) ज़्यादातर समय खाली रहते हैं। जब ऐप लाइव होती है, तो हर विज़िटर एक ऐसी रिक्वेस्ट जेनरेट करता है जिसे दो मुख्य चीज़ों की ज़रूरत होती है:

  • CPU (central processing unit) – वह प्रोसेसर जो हर लूप, फंक्शन और कैलकुलेशन को चलाता है। इसे एक ऐसे शेफ की तरह समझें जो एक बार में केवल सीमित संख्या में व्यंजन तैयार कर सकता है। एक ऑर्डर तुरंत सर्व कर दिया जाता है; सौ ऑर्डर का मतलब है कि शेफ अभी भी उसी गति से काम करता है, लेकिन ग्राहकों को ज़्यादा इंतज़ार करना पड़ता है।
  • RAM (random-access memory) – रिक्वेस्ट हैंडल करते समय CPU को जिस डेटा की आवश्यकता होती है, उसके लिए अस्थायी स्टोरेज। यह एक डेस्क की तरह है जहाँ शेफ प्रत्येक व्यंजन के लिए सामग्री रखता है। यदि डेस्क भर जाता है, तो शेफ को तब तक नए ऑर्डर लेना बंद करना होगा जब तक कि जगह खाली न हो जाए।

जब हज़ारों यूज़र्स एक साथ लॉग इन करते हैं, तो प्रत्येक रिक्वेस्ट CPU समय का अपना हिस्सा और RAM का अपना हिस्सा लेती है। सर्वर के दोनों रिसोर्सेज का सीमित पूल रिक्वेस्ट के बीच विभाजित हो जाता है, और कतार (queue) बढ़ती जाती है। सर्वर खुद धीमा नहीं हुआ है; प्रत्येक रिक्वेस्ट के लिए प्रतीक्षा समय (wait time) बढ़ गया है।

"बस एक बड़ा बॉक्स खरीद लें" का लालच

एक सामान्य पहली प्रतिक्रिया मशीन को अपग्रेड करना है – इस प्रक्रिया को vertical scaling कहा जाता है। अधिक CPU कोर या अधिक RAM जोड़ने से क्षमता में सुधार होता है: 4 कोर से 16, या 8 GB से 64 GB पर जाने से किसी भी कोड को बदले बिना ट्रैफिक के बड़े उछाल को संभाला जा सकता है।

हालाँकि, vertical scaling की एक सीमा (ceiling) होती है:

  • भौतिक सीमाएँ (Physical limits) – प्रत्येक मदरबोर्ड केवल एक निश्चित संख्या में कोर और सीमित मात्रा में मेमोरी को ही होस्ट कर सकता है।
  • घटता हुआ लाभ (Diminishing returns) – प्रत्येक अतिरिक्त कोर या गीगाबाइट पिछले वाले की तुलना में अधिक महंगा होता है, जबकि प्रदर्शन में होने वाला लाभ कम होता जाता है।
  • विफलता का एकल बिंदु (Single point of failure) – यदि ओवरसाइज़्ड सर्वर डाउन हो जाता है, तो पूरी सेवा गायब हो जाती है।

इन बाधाओं के कारण, इंडस्ट्री के दिग्गज – स्ट्रीमिंग प्लेटफॉर्म, सर्च इंजन, ई-कॉमर्स साइट्स – एक सिंगल मॉन्स्टर मशीन से दूर हट गए हैं।

विकल्प: कई छोटे बॉक्सों में लोड को फैलाना

एक ऊँचा टॉवर बनाने के बजाय, ऑपरेटर्स मध्यम आकार के अधिक सर्वर जोड़ते हैं और उन्हें ट्रैफिक साझा करने देते हैं। यह horizontal scaling दृष्टिकोण प्रत्येक मशीन को एक आरामदायक परफॉरमेंस एनवेलप (performance envelope) के भीतर रखता है और वर्टिकल अपग्रेड के घातीय लागत वक्र (exponential cost curve) से बचाता है।

कई मशीनों के समन्वय (coordinating) के लिए एक load balancer की आवश्यकता होती है – एक सॉफ्टवेयर या हार्डवेयर जो प्रत्येक आने वाली रिक्वेस्ट प्राप्त करता है और उसे सबसे अधिक उपलब्ध क्षमता वाले सर्वर पर भेज देता है। बैलेंसर क्लाइंट से जटिलता को छिपा देता है; यूज़र के नज़रिए से साइट अभी भी एक सिंगल एंडपॉइंट की तरह दिखती है।

Horizontal scaling लचीलापन (resilience) भी लाता है। यदि एक नोड क्रैश हो जाता है, तो बैलेंसर बस ट्रैफिक को शेष स्वस्थ नोड्स पर रूट कर देता है, जिससे सेवा चालू रहती है।

जब आप मशीनें जोड़ना शुरू करें तो किन बातों का ध्यान रखें

  • Stateless design – रिक्वेस्ट केवल एक विशिष्ट सर्वर की मेमोरी में संग्रहीत डेटा पर निर्भर नहीं होनी चाहिए; अन्यथा एक यूज़र को ऐसे नोड पर भेजा जा सकता है जिसमें आवश्यक संदर्भ (context) की कमी हो। साझा कैश (shared caches) या डेटाबेस का उपयोग करने से यह समस्या हल हो जाती है।
  • Health checks – बैलेंसर को विफल होते सर्वर का जल्दी पता लगाने और उसे ट्रैफिक भेजना बंद करने में सक्षम होना चाहिए।
  • Auto-scaling policies – कई क्लाउड प्लेटफॉर्म आपको थ्रेशोल्ड (CPU उपयोग, रिक्वेस्ट लेटेंसी) परिभाषित करने की अनुमति देते हैं जो स्वचालित रूप से instances को शुरू या बंद कर देते हैं, जिससे लागत मांग के अनुरूप बनी रहती है।

काउंटर-पॉइंट: vertical scaling खत्म नहीं हुई है

छोटी टीमों या कम ट्रैफिक वाली ऐप्स के लिए, एक सिंगल शक्तिशाली सर्वर सबसे सरल और सस्ता समाधान हो सकता है। यदि ट्रैफिक स्पाइक अनुमानित है (जैसे, एक निर्धारित उत्पाद लॉन्च), तो नए instances का पूरा बेड़ा तैयार करने की तुलना में एक अस्थायी वर्टिकल अपग्रेड अधिक व्यावहारिक हो सकता है।

मुख्य बात यह पहचानना है कि "बड़ा बॉक्स" वाला तरीका कब आनुपातिक मूल्य देना बंद कर देता है और वितरण (distribution) के लिए योजना बनाना शुरू करना है।

निष्कर्ष (Takeaway)

लॉन्च के बाद सर्वर का धीमा होना आमतौर पर रिसोर्स-कंटेंशन (resource-contention) की समस्या होती है, न कि कोड की कोई खराबी। CPU साइकिल और RAM स्लॉट सीमित होते हैं, और जब बहुत सारे अनुरोध (requests) एक साथ आते हैं, तो वे कतार (queue) में लग जाते हैं, जिससे रिस्पॉन्स टाइम बढ़ जाता है। वर्टिकल स्केलिंग (Vertical scaling) आपको थोड़ा और अतिरिक्त मार्जिन (headroom) तो देती है, लेकिन जल्द ही यह भौतिक और आर्थिक सीमाओं से टकरा जाती है। हॉरिजॉन्टल स्केलिंग (Horizontal scaling)—एक लोड बैलेंसर के पीछे अधिक सामान्य सर्वर जोड़ना—जैसे-जैसे ट्रैफिक बढ़ता है, यह एक सस्ता और अधिक लचीला (resilient) विकल्प प्रदान करती है। जिस क्षण आप कतार (queue) को लंबा होते हुए देखते हैं, तभी यह मूल्यांकन करने का समय आ जाता है कि क्या कुछ और कोर (cores) पर्याप्त होंगे या आपको लोड को कई मशीनों पर फैलाना शुरू कर देना चाहिए।

स्रोत: dev.to लेख “Why Servers Slow Down – CPU, RAM and the hidden cost of every request.”