डेव्हलपर्स पाहतात की त्यांचे नुकतेच लाँच झालेले ॲप काही हजार युजर्सनी “go” क्लिक करताच मंदावू लागते, आणि हा स्लोडाउन (slowdown) क्वचितच कोडमधील बग असतो – तो प्रत्यक्षात सर्व्हरच्या CPU आणि RAM मधील जागेसाठीचा संघर्ष असतो. हा अडथळा (bottleneck) लाँग पेज लोड्स, टाइम-आउट्स किंवा थेट क्रॅशच्या स्वरूपात दिसून येतो, आणि यामुळे युजर एक्सपिरियन्स, महसूल आणि ब्रँडवरील विश्वास यावर परिणाम होतो.

प्रयोगशाळेत व्यवस्थित चालणारा सर्व्हर प्रोडक्शनमध्ये का मंदावू शकतो

डेव्हलपमेंट दरम्यान एक डेव्हलपर फक्त काही मोजक्या विनंत्या (requests) पाठवतो, त्यामुळे सर्व्हरची संसाधने (resources) बहुतेक वेळ रिकामी असतात. जेव्हा ॲप लाईव्ह जाते, तेव्हा प्रत्येक व्हिजिटर एक विनंती जनरेट करतो ज्यासाठी दोन मुख्य घटक आवश्यक असतात:

  • CPU (central processing unit) – प्रत्येक लूप, फंक्शन आणि कॅल्क्युलेशन चालवणारा प्रोसेसर. याला एका अशा शेफसारखे समजा जो एका वेळी मर्यादित पदार्थच तयार करू शकतो. एक ऑर्डर दिली तर ती लगेच मिळते; पण शंभर ऑर्डर्स आल्या तर शेफ त्याच वेगाने काम करत राहील, परंतु ग्राहकांना जास्त वेळ वाट पाहावी लागेल.
  • RAM (random-access memory) – विनंती हाताळताना CPU ला आवश्यक असलेल्या डेटासाठीचे तात्पुरते स्टोरेज. हे एखाद्या डेस्कसारखे आहे जिथे शेफ प्रत्येक पदार्थासाठी लागणारे साहित्य ठेवतो. जर डेस्क पूर्ण भरला असेल, तर जागा मोकळी होईपर्यंत शेफ नवीन ऑर्डर्स घेणे थांबवावा लागतो.

जेव्हा हजारो युजर्स एकाच वेळी लॉग इन करतात, तेव्हा प्रत्येक विनंती स्वतःचा CPU वेळ आणि स्वतःचा RAM भाग घेते. सर्व्हरकडे असलेल्या दोन्ही संसाधनांचा मर्यादित साठा विनंत्यांमध्ये विभागला जातो आणि रांग (queue) वाढत जाते. सर्व्हर स्वतः संथ झालेला नसतो; तर प्रत्येक विनंतीसाठी लागणारा प्रतीक्षा वेळ वाढलेला असतो.

“फक्त एक मोठा सर्व्हर विकत घ्या” असा मोह

पहिली प्रतिक्रिया सहसा मशीन अपग्रेड करण्याची असते – या पद्धतीला vertical scaling म्हणतात. अधिक CPU कोअर्स किंवा अधिक RAM जोडल्याने क्षमता नक्कीच सुधारते: ४ कोअर्सकडून १६ कोअर्सकडे किंवा ८ GB कडून ६४ GB कडे जाणे, कोणताही कोड न बदलता ट्रॅफिकचा मोठा भार पेलू शकते.

तथापि, व्हर्टिकल स्केलिंगला काही मर्यादा येतात:

  • भौतिक मर्यादा (Physical limits) – प्रत्येक मदरबोर्ड केवळ ठराविक संख्येने कोअर्स आणि मर्यादित मेमरी होस्ट करू शकतो.
  • कमी होत जाणारा परतावा (Diminishing returns) – प्रत्येक अतिरिक्त कोअर किंवा गिगाबाइट मागील पेक्षा जास्त महाग असतो, तर कामगिरीतील वाढ मात्र कमी होत जाते.
  • सिंगल पॉइंट ऑफ फेल्युअर (Single point of failure) – जर तो मोठा सर्व्हर डाऊन झाला, तर संपूर्ण सेवा बंद पडते.

या मर्यादांमुळे, उद्योगातील दिग्गज कंपन्या – स्ट्रीमिंग प्लॅटफॉर्म्स, सर्च इंजिन्स, ई-कॉमर्स साइट्स – एका मोठ्या मशीनवर अवलंबून राहण्याऐवजी इतर पद्धतींकडे वळल्या आहेत.

पर्याय: अनेक लहान मशीन्सवर भार विभागणे

एक उंच टॉवर बांधण्याऐवजी, ऑपरेटर्स मध्यम आकाराचे अधिक सर्व्हर्स जोडतात आणि त्यांना ट्रॅफिक शेअर करू देतात. हा horizontal scaling दृष्टिकोन प्रत्येक मशीनला कार्यक्षमतेच्या मर्यादेत ठेवतो आणि व्हर्टिकल अपग्रेड्समुळे येणाऱ्या वाढत्या खर्चापासून वाचवतो.

अनेक मशीन्सचे समन्वय साधण्यासाठी load balancer ची आवश्यकता असते – हे एक सॉफ्टवेअर किंवा हार्डवेअर आहे जे प्रत्येक येणारी विनंती स्वीकारते आणि ज्या सर्व्हरकडे सर्वाधिक उपलब्ध क्षमता आहे, त्याकडे ती पाठवते. लोड बॅलन्सर क्लायंटकडून येणारी गुंतागुंत लपवून ठेवतो; युजरच्या दृष्टीने साइट अजूनही एकच एंडपॉइंट (endpoint) असल्यासारखी दिसते.

हॉरिझॉन्टल स्केलिंगमुळे लवचिकता (resilience) देखील येते. जर एक नोड क्रॅश झाला, तर बॅलन्सर फक्त ट्रॅफिक उर्वरित कार्यरत नोड्सकडे वळवतो, ज्यामुळे सेवा सुरू राहते.

मशीन्स जोडायला सुरुवात करताना कोणत्या गोष्टींकडे लक्ष द्यावे

  • Stateless design – विनंत्या केवळ एका विशिष्ट सर्व्हरच्या मेमरीमध्ये साठवलेल्या डेटावर अवलंबून नसाव्यात; अन्यथा युजरला अशा नोडवर पाठवले जाऊ शकते जिथे आवश्यक संदर्भ (context) उपलब्ध नसेल. यासाठी शेअर कॅशे (shared caches) किंवा डेटाबेस वापरल्याने ही समस्या सुटते.
  • Health checks – बॅलन्सरला एखादा सर्व्हर निकामी होत असल्याचे त्वरित ओळखता आले पाहिजे आणि त्याला ट्रॅफिक पाठवणे थांबवले पाहिजे.
  • Auto-scaling policies – अनेक क्लाउड प्लॅटफॉर्म्स तुम्हाला काही मर्यादा (CPU वापर, विनंती विलंब/latency) परिभाषित करण्याची परवानगी देतात, ज्यामुळे मागणीनुसार इन्स्टन्स आपोआप सुरू किंवा बंद होतात आणि खर्च नियंत्रणात राहतो.

प्रतिवाद: व्हर्टिकल स्केलिंग संपलेले नाही

लहान टीम्स किंवा कमी ट्रॅफिक असलेल्या ॲप्ससाठी, एक शक्तिशाली सर्व्हर हा सर्वात सोपा आणि स्वस्त उपाय असू शकतो. जर ट्रॅफिकचा वाढता आकडा अंदाजित असेल (उदा. नियोजित उत्पादन लाँच), तर नवीन इन्स्टन्सचा संपूर्ण ताफा तयार करण्यापेक्षा तात्पुरते व्हर्टिकल अपग्रेड करणे अधिक व्यावहारिक ठरू शकते.

महत्त्वाची गोष्ट म्हणजे, "मोठा सर्व्हर" घेण्याची युक्ती कधी प्रमाणशीर फायदा देणे थांबवते हे ओळखणे आणि वितरणासाठी (distribution) नियोजन सुरू करणे.

मुख्य निष्कर्ष

लाँच नंतर सर्व्हरचा वेग मंदावणे हे सहसा 'रिसोर्स-कन्टेन्शन' (resource-contention) मुळे होते, कोडमधील दोषामुळे नाही. CPU सायकल आणि RAM स्लॉट्स मर्यादित असतात आणि जेव्हा एकाच वेळी अनेक विनंत्या (requests) येतात, तेव्हा त्या रांगेत (queue) लागतात, ज्यामुळे प्रतिसाद मिळण्याचा वेळ (response time) वाढतो. व्हर्टिकल स्केलिंग (Vertical scaling) तुम्हाला थोडी अधिक क्षमता देते, परंतु लवकरच ती भौतिक आणि आर्थिक मर्यादांच्या पलीकडे जाते. हॉरिझॉन्टल स्केलिंग—म्हणजेच लोड बॅलन्सरच्या (load balancer) मागे अधिक मध्यम क्षमतेचे सर्व्हर्स जोडणे—ट्रॅफिक वाढल्यास एक स्वस्त आणि अधिक लवचिक (resilient) मार्ग प्रदान करते. ज्या क्षणी तुम्हाला रांग (queue) वाढत असल्याचे जाणवेल, तेव्हा हे तपासण्याची वेळ येते की काही अधिक कोअर्स (cores) पुरेसे ठरतील की तुम्ही लोड अनेक मशीन्सवर विभागण्यास सुरुवात केली पाहिजे.

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