एका डेव्हलपरने क्लायंट-साइड पोलिंग इंटरव्हल (polling interval) ३० सेकंदांवरून १५ मिनिटांपर्यंत वाढवून Neon चे सर्व्हरलेस-डेटाबेस कॉम्प्युट चार्जेस (compute charges) कमी केले. या जास्त वेळेच्या विश्रांतीमुळे डेटाबेस पुरेसा वेळ 'idle' राहू शकतो, ज्यामुळे तो 'scale to zero' स्थितीला पोहोचतो आणि सततच्या ३०-सेकंद पोलिंगमुळे खर्च होणारे कॉम्प्युट क्रेडिट्स वाचतात.
Neon त्याचे कॉम्प्युट इंजिन जितका वेळ चालते, त्या प्रत्येक सेकंदासाठी बिल आकारते. एका सामान्य सर्व्हरलेस सेटअपमध्ये, कोणतीही विनंती (request)—ती कितीही लहान असली तरी—इंजिनला 'awake' ठेवते. लेखकाचे टीव्ही डॅशबोर्ड दर अर्ध्या मिनिटाला डेटाबेसमध्ये क्वेरी करत होते, जरी प्रदर्शित होणारा डेटा केवळ वापरकर्त्याने मॅन्युअली सिंक केल्यावर किंवा नवीन ब्रॉडकास्ट सुरू झाल्यावरच बदलत असे. या पद्धतीमुळे Neon चे कॉम्प्युट पूल कधीही त्या 'zero-state' मध्ये पोहोचू शकले नाही ज्यामुळे बिलिंग थांबते, परिणामी Vercel कॉस्ट डॅशबोर्डवर नियमितपणे खर्चाचे स्पाइक्स (spikes) दिसत होते.
मूळ पोलिंग का महत्त्वाचे होते
- डॅशबोर्ड हा पूर्णपणे क्लायंट-साइड React कंपोनंट होता, त्यामुळे प्रत्येक ब्राउझर इन्स्टन्स थेट Neon ला हिट करत होता.
- Neon चे प्राइसिंग खर्चाला सक्रिय कॉम्प्युट वेळेशी जोडते, विनंतीच्या संख्येशी (request count) नाही, त्यामुळे दर ३० सेकंदाला होणारी एक हिट देखील मूलभूत शुल्क (baseline charge) कायम राखत होती.
- लेखकाच्या Vercel मॉनिटरिंगमध्ये ट्रॅफिक आणि Neon कॉम्प्युट वापरामध्ये सहसंबंध (correlation) दिसून आला, ज्यावरून हे स्पष्ट झाले की पोलिंगमुळे डेटाबेस 'awake' राहत होता.
अयशस्वी उपाय (Failed workarounds)
एक जलद 'debounce' वापरणे—म्हणजे शेवटच्या युजर इंटरॅक्शननंतर विनंतीला विलंब करणे—फायद्याचे ठरले नाही कारण टाइमर अजूनही दर ३० सेकंदांनी सुरू होत होता. मी Vercel Edge Functions वापरण्याचाही प्रयत्न केला, परंतु त्यामुळे गुंतागुंत (complexity) खूप वाढली.
सोपा उपाय
केवळ रिफ्रेश इंटरव्हल परिभाषित करणारा एक constant बदलणे आवश्यक होते:
- ३० सेकंद → ५ मिनिटे
- त्यानंतर ५ मिनिटे → १५ मिनिटे
१५ मिनिटांच्या अंतराने, Neon ला निष्क्रियता (inactivity) ओळखण्यासाठी आणि त्याचे कॉम्प्युट रिसोर्सेस 'spin down' करण्यासाठी पुरेसा वेळ मिळतो. डॅशबोर्ड कार्यान्वित राहतो: वापरकर्ते जेव्हा मॅन्युअली रिफ्रेश करतात तेव्हा त्यांना अद्याप नवीनतम डेटा दिसतो, आणि अधूनमधून होणारे ऑटोमॅटिक पोलिंग सततच्या हालचालींशिवाय नवीन ब्रॉडकास्ट पकडते.
क्लायंट-साइड पोलिंग का ठेवावे?
- साधेपणा – कोणतेही अतिरिक्त सर्व्हरलेस फंक्शन्स किंवा बिल्ड स्टेप्सची गरज नाही.
- वापरकर्त्यांच्या अपेक्षा – डॅशबोर्ड आधीच एका क्लायंट ॲपसारखा वागतो; मॅन्युअल क्लिक केल्यावर अद्याप त्वरित अपडेट मिळते.
- कॉस्ट मॉडेलशी सुसंगतता – Neon प्रति विनंती (request) नाही, तर प्रति सेकंद कॉम्प्युटसाठी शुल्क आकारते, त्यामुळे वारंवारता (frequency) कमी केल्याने थेट बिल कमी होते.
सर्व्हरलेस डेव्हलपर्ससाठी धडे
- तुमच्या डेटाच्या वास्तविक जगातील अपडेटच्या वेगाशी (cadence) पोलिंगची वारंवारता जुळवा. जर डेटासेट तासाला फक्त काही वेळा बदलत असेल, तर १५ मिनिटांचा इंटरव्हल अनेकदा पुरेसा असतो.
- सर्व्हरलेस वातावरणात वारंवार पोलिंग करणे हा एक छुपा खर्च वाढवणारा घटक आहे; दर मिनिटाला होणारी एक अतिरिक्त विनंती डेटाबेस कधीही 'scale down' होण्यापासून रोखू शकते.
- आर्किटेक्चरल बदलांशिवाय (architectural overhaul) केवळ लहान कॉन्फिगरेशन बदल करून मोठ्या प्रमाणात बचत केली जाऊ शकते.
थोडक्यात सांगायचे तर: एका सिंगल constant बदलामुळे सतत 'awake' राहणाऱ्या डेटाबेसला खऱ्या अर्थाने सर्व्हरलेस कंपोनंटमध्ये रूपांतरित केले, ज्यामुळे डॅशबोर्डची उपयुक्तता कायम ठेवून कॉम्प्युट खर्च कमी झाला. Neon किंवा तत्सम प्रति-सेकंद कॉम्प्युट सेवा वापरणाऱ्या कोणत्याही टीमसाठी, पोलिंग इंटरव्हल्सचा पुनर्विचार करणे हा आजच तपासून पाहण्यासारखा एक सोपा आणि फायदेशीर मार्ग आहे.
