Meteor 3.5 ڈویلپرز کو صرف ایک انوائرمنٹ ویری ایبل (environment variable) کے ذریعے SockJS کو چھوڑ کر uWebSockets.js استعمال کرنے کی سہولت دیتا ہے، جس سے ان ایپس کے لیے CPU، RAM اور garbage-collection کے اخراجات میں نمایاں کمی کا وعدہ کیا گیا ہے جو میتھڈ کالز (method calls) پر بہت زیادہ انحصار کرتی ہیں۔

یہ تبدیلی کیوں اہم ہے

اپنے آغاز سے ہی، Meteor ہر DDP (Distributed Data Protocol) پیغام کو SockJS کے ذریعے بھیجتا رہا ہے، جو کہ ایک JavaScript fallback ہے جو ہر جگہ کام کرتا ہے لیکن اسے تیز رفتار (raw speed) کے لیے ڈیزائن نہیں کیا گیا تھا۔ نیا ورژن ٹرانسپورٹ لیئر (transport layer) کو الگ کر دیتا ہے، اور ایک ایسا پلگ ان پوائنٹ فراہم کرتا ہے جو کسی بھی ایسی WebSocket امپلیمنٹیشن کو قبول کر سکتا ہے جو DDP کی ضروریات کے مطابق ہو۔ آغاز پر DDP_TRANSPORT=uws سیٹ کرنے سے ڈیفالٹ کو uWebSockets.js سے بدل دیا جاتا ہے، جو کہ ہائی تھرو پٹ (high throughput) کے لیے مشہور ایک C/C++ پر مبنی سرور ہے۔

کارکردگی کا پہلو

ریلیز کے ساتھ فراہم کردہ بینچ مارکس (Benchmarks) درج ذیل نتائج دکھاتے ہیں:

  • CPU کا استعمال 9% کم ہو گیا
  • RAM کا استعمال 11% کم ہو گیا
  • Garbage-collection کے وقفے کا وقت (pause time) 26% کم ہو گیا
  • Micro-benchmarks میں تھرو پٹ (Throughput) 1.6x بڑھ گیا

یہ فوائد اس وقت نظر آتے ہیں جب کوئی ایپلی کیشن بہت زیادہ RPC طرز کے میتھڈ کالز کرتی ہے۔ ٹرانسپورٹ خود صرف اس صورت میں رکاوٹ (bottleneck) بنتا ہے جب ایپلی کیشن کے بزنس لاجک کو آپٹیمائز (optimise) کر لیا گیا ہو۔ لہذا، یہ تبدیلی براہ راست سرور کے اخراجات میں کمی کا باعث بن سکتی ہے۔

اسے آج ہی کیسے آزمائیں

کسی علیحدہ بائنری کی ضرورت نہیں ہے—صرف Meteor 3.5 کافی ہے۔ ایپ کو اس طرح چلائیں:

DDP_TRANSPORT=uws meteor run

uWebSockets.js سرور اپنے مخصوص پورٹ (ڈیفالٹ 5001) پر کام کرتا ہے۔ جب ایک ہی ہوسٹ پر متعدد Meteor instances چل رہے ہوں، تو ٹکراؤ (collisions) سے بچنے کے لیے ہر ایک کو METEOR_SETTINGS کے ذریعے ایک الگ uws.port تفویض کرنا ضروری ہے۔

کسے فائدہ ہوگا، اور کسے زیادہ فرق محسوس نہیں ہوگا

  • RPC پر مبنی بھاری ورک لوڈز (RPC-heavy workloads) – وہ سروسز جو فی درخواست بہت سے میتھڈز کال کرتی ہیں، وہ CPU سائیکلز اور میموری بچا سکتی ہیں، جس سے اسکیلنگ (scaling) کے دباؤ میں کمی آتی ہے۔
  • Pub/Sub پر مبنی ایپس – پبلش/سبسکرائب پیٹرنز میں زیادہ تر تاخیر (latency) ڈیٹا-ڈف (data-diff) کیلکولیشنز کی وجہ سے ہوتی ہے، نہ کہ ٹرانسپورٹ کی وجہ سے، اس لیے رفتار میں اضافہ معمولی ہوگا۔

یہ تبدیلی اختیاری ہے؛ SockJS ڈیفالٹ کے طور پر برقرار رہے گا، تاکہ ان ماحول کے ساتھ مطابقت (compatibility) برقرار رہے جہاں نیٹیو WebSockets دستیاب نہیں ہیں۔

توازن اور احتیاطی تدابیر

ٹرانسپورٹ تبدیل کرنے سے ایک چھوٹا سا آپریشنل مرحلہ شامل ہو جاتا ہے: ایک اضافی پورٹ کا انتظام کرنا اور اس بات کو یقینی بنانا کہ یہ دوسری سروسز کے ساتھ ٹکرائے نہیں۔ چونکہ uWebSockets.js ایک نیٹیو ماڈیول ہے، اس لیے اس میں بائنری ڈیپینڈنسیز (binary dependencies) کے عام مسائل شامل ہیں—ڈیپلائمنٹ ہوسٹ پر بلڈ ٹولز (build tools) کا ہونا ضروری ہے، اور لائبریری کی کسی بھی مستقبل کی اپ ڈیٹ کو ایپ کے کوڈ بیس کے ساتھ ٹیسٹ کرنے کی ضرورت ہوگی۔

Meteor کی ٹرانسپورٹ لیئر کا مستقبل کیا ہے

ایک واضح حد (boundary) فراہم کر کے، Meteor اب کمیونٹی کو متبادل ٹرانسپورٹس کے ساتھ تجربہ کرنے کی دعوت دیتا ہے—خواہ وہ مخصوص سیکیورٹی ضروریات کے لیے ہوں، کسٹم پروٹوکول ایکسٹینشنز کے لیے ہوں، یا مزید کارکردگی کی بہتری (performance tuning) کے لیے ہوں۔ یہ دیکھنا کہ تھرڈ پارٹی امپلیمنٹیشنز کتنی تیزی سے سامنے آتی ہیں، اس بات کی نشاندہی کرے گا کہ آیا یہ پلگ ایبل ماڈل Meteor کے آرکیٹیکچر کا مستقل حصہ بن جاتا ہے یا نہیں۔

خلاصہ: Meteor 3.5 کا پلگ ایبل DDP ٹرانسپورٹ آپ کو ایک ہی کمانڈ میں پرانے SockJS اسٹیک کو uWebSockets.js سے بدلنے کی اجازت دیتا ہے، جو RPC پر مبنی ایپلی کیشنز کے لیے 1.6x تک زیادہ تھرو پٹ اور وسائل کی خاطر خواہ بچت فراہم کرتا ہے، جبکہ ان ورک لوڈز کے لیے موجودہ سیٹ اپ کو برقرار رکھتا ہے جنہیں اس اضافے کی ضرورت نہیں ہے۔