Meteor 3.5 मुळे डेव्हलपर्स एका सिंगल एन्व्हायरनमेंट व्हेरिएबलद्वारे (environment variable) SockJS ऐवजी uWebSockets.js वापरू शकतात, ज्यामुळे मेथड कॉल्सवर (method calls) मोठ्या प्रमाणावर अवलंबून असलेल्या ॲप्ससाठी CPU, RAM आणि गार्बेज-कलेक्शन (garbage-collection) खर्च लक्षणीयरीत्या कमी होण्याची शक्यता आहे.

हा बदल का महत्त्वाचा आहे

त्याच्या लाँचपासून, Meteor ने प्रत्येक DDP (Distributed Data Protocol) मेसेज SockJS द्वारे पाठवला आहे. SockJS हा एक JavaScript fallback आहे जो सर्वत्र काम करतो, परंतु तो उच्च वेगासाठी (raw speed) डिझाइन केलेला नव्हता. नवीन रिलीज ट्रान्सपोर्ट लेयरला (transport layer) वेगळे करते आणि एक प्लग-इन पॉइंट उपलब्ध करून देते, जो DDP च्या अपेक्षांनुसार कोणत्याही WebSocket अंमलबजावणीला (implementation) स्वीकारू शकतो. लाँच करताना DDP_TRANSPORT=uws सेट केल्यास डिफॉल्ट ऐवजी uWebSockets.js वापरले जाते, जे उच्च थ्रूपुटसाठी (high throughput) ओळखले जाणारे C/C++-आधारित सर्व्हर आहे.

परफॉर्मन्सचा पैलू

रिलीजसोबत दिलेल्या बेंचमार्कनुसार खालील गोष्टी दिसून येतात:

  • CPU वापर ९% ने कमी
  • RAM वापर ११% ने कमी
  • गार्बेज-कलेक्शन पॉज टाइम २६% ने कमी
  • मायक्रो-बेंचमार्क्समध्ये थ्रूपुट १.६ पट वाढला

जेव्हा एखादे ॲप्लिकेशन अनेक RPC-स्टाईल मेथड कॉल्स करते, तेव्हा हे फायदे दिसून येतात. जेव्हा ॲप्लिकेशनचे बिझनेस लॉजिक ऑप्टिमाइझ केले जाते, तेव्हाच ट्रान्सपोर्ट स्वतः अडथळा (bottleneck) ठरते, त्यामुळे हा बदल थेट सर्व्हर खर्च कमी करण्यास मदत करू शकतो.

आजच हे कसे वापरून पाहाल

यासाठी कोणत्याही वेगळ्या बायनरीची गरज नाही—फक्त Meteor 3.5 पुरेसे आहे. ॲप खालीलप्रमाणे चालवा:

DDP_TRANSPORT=uws meteor run

uWebSockets.js सर्व्हर त्याच्या स्वतःच्या पोर्टवर (डिफॉल्ट ५००१) ऐकतो (listens). जेव्हा एकाच होस्टवर अनेक Meteor इन्स्टन्स चालतात, तेव्हा कोलिजन (collisions) टाळण्यासाठी METEOR_SETTINGS द्वारे प्रत्येक इन्स्टन्सला एक वेगळा uws.port नियुक्त करणे आवश्यक आहे.

कोणाला फायदा होईल आणि कोणाला फारसा फरक जाणवणार नाही

  • RPC-हेवी वर्कलोड्स – ज्या सेवा प्रति रिक्वेस्ट अनेक मेथड्स कॉल करतात, त्यांना CPU सायकल आणि मेमरीची बचत होऊन स्केलिंगचा ताण कमी करण्यास मदत होईल.
  • Pub/Sub-केंद्रित ॲप्स – पब्लिश/सबस्क्राईब पॅटर्नमधील बहुतेक लॅटन्सी (latency) डेटा-डिफ (data-diff) कॅल्क्युलेशनमुळे येते, ट्रान्सपोर्टमुळे नाही, त्यामुळे येथे वेगातील वाढ मर्यादित असेल.

हा बदल ऐच्छिक (opt-in) आहे; SockJS डिफॉल्ट राहते, ज्यामुळे ज्या वातावरणात नेटिव्ह WebSockets उपलब्ध नाहीत, त्यांच्याशी सुसंगतता (compatibility) कायम राहते.

तडजोड आणि खबरदारी

ट्रान्सपोर्ट बदलल्यामुळे एक लहान ऑपरेशनल स्टेप वाढते: एक अतिरिक्त पोर्ट व्यवस्थापित करणे आणि तो इतर सेवांशी न आदळेल याची खात्री करणे. uWebSockets.js हे नेटिव्ह मॉड्यूल असल्याने, त्यासोबत बायनरी डिपेंडन्सीजचे (binary dependencies) नेहमीचे प्रश्न येतात—डिप्लॉयमेंट होस्टवर बिल्ड टूल्स असणे आवश्यक आहे आणि लायब्ररीमधील कोणत्याही भविष्यातील अपडेट्सची ॲप्लिकेशनच्या कोडबेसवर चाचणी घेणे आवश्यक असेल.

Meteor च्या ट्रान्सपोर्ट लेयरसाठी पुढे काय?

एक स्पष्ट सीमा (boundary) उपलब्ध करून देऊन, Meteor आता समुदायाला पर्यायी ट्रान्सपोर्ट्ससोबत प्रयोग करण्यासाठी आमंत्रित करत आहे—मग ते विशेष सुरक्षा आवश्यकतांसाठी असो, कस्टम प्रोटोकॉल एक्स्टेंशन्ससाठी असो किंवा अधिक परफॉर्मन्स ट्यूनिंगसाठी असो. थर्ड-पार्टी अंमलबजावणी (implementations) किती वेगाने समोर येतात, यावरून हे समजेल की प्लगेबल मॉडेल हे Meteor च्या आर्किटेक्चरचा कायमस्वरूपी भाग बनेल की नाही.

थोडक्यात सांगायचे तर: Meteor 3.5 चे प्लगेबल DDP ट्रान्सपोर्ट तुम्हाला एका सिंगल कमांडमध्ये जुना SockJS स्टॅक uWebSockets.js ने बदलण्याची सुविधा देते. यामुळे RPC-इंटेंसिव्ह ॲप्लिकेशन्ससाठी १.६ पट अधिक थ्रूपुट आणि संसाधनांची (resources) बचत मिळते, तर ज्या वर्कलोड्सना या वेगाची गरज नाही, त्यांच्यासाठी सध्याची सेटअप तशीच राहते.