يتيح Meteor 3.5 للمطورين الاستغناء عن SockJS لصالح uWebSockets.js باستخدام متغير بيئة واحد، مما يعد بخفض ملحوظ في تكاليف المعالج (CPU) والذاكرة العشوائية (RAM) وعمليات جمع القمامة (garbage-collection) للتطبيقات التي تعتمد بشكل كبير على استدعاءات الدوال (method calls).

لماذا يهم هذا التغيير

منذ إطلاقه، يقوم Meteor بتوجيه كل رسالة DDP (Distributed Data Protocol) عبر SockJS، وهو بديل يعتمد على JavaScript يعمل في كل مكان ولكنه لم يُصمم من أجل السرعة القصوى. يقوم الإصدار الجديد بفصل طبقة النقل (transport layer)، مما يوفر نقطة توصيل (plug-in point) تقبل أي تنفيذ لـ WebSocket يتوافق مع توقعات DDP. يؤدي ضبط DDP_TRANSPORT=uws عند التشغيل إلى استبدال الخيار الافتراضي بـ uWebSockets.js، وهو خادم مدعوم بلغة C/C++ ومعروف بقدرته العالية على معالجة البيانات (high throughput).

زاوية الأداء

تُظهر اختبارات الأداء (Benchmarks) المرفقة مع الإصدار ما يلي:

  • انخفاض استخدام المعالج (CPU) بنسبة 9%
  • انخفاض استهلاك الذاكرة (RAM) بنسبة 11%
  • تقليل وقت توقف عملية جمع القمامة (Garbage-collection) بنسبة 26%
  • زيادة في معدل المعالجة (Throughput) بمقدار 1.6 ضعف في اختبارات الأداء الدقيقة (micro-benchmarks)

تظهر هذه المكاسب عندما يقوم التطبيق بإجراء العديد من استدعاءات الدوال بأسلوب RPC. لا تصبح عملية النقل نفسها هي عنق الزجاجة إلا بعد تحسين منطق العمل (business logic) الخاص بالتطبيق، لذا يمكن أن يترجم هذا التحول مباشرة إلى تكاليف خادم أقل.

كيف تجربه اليوم

لا يلزم وجود ملف ثنائي (binary) منفصل — فقط Meteor 3.5. قم بتشغيل التطبيق باستخدام:

DDP_TRANSPORT=uws meteor run

يستمع خادم uWebSockets.js على المنفذ الخاص به (الافتراضي 5001). عندما تشترك عدة مثيلات (instances) من Meteor في مضيف واحد، يجب تعيين uws.port متميز لكل منها عبر METEOR_SETTINGS لتجنب التعارضات.

من المستفيد، ومن قد لا يلاحظ فرقاً كبيراً

  • أعباء العمل الكثيفة بأسلوب RPC – الخدمات التي تستدعي العديد من الدوال لكل طلب ستوفر دورات المعالج والذاكرة، مما يخفف من ضغوط التوسع (scaling).
  • التطبيقات التي تعتمد على Pub/Sub – يأتي معظم التأخير (latency) في أنماط النشر/الاشتراك (publish/subscribe) من حسابات فروق البيانات (data-diff)، وليس من عملية النقل، لذا فإن تحسن السرعة سيكون متواضعاً.

هذا التغيير اختياري؛ حيث يظل SockJS هو الخيار الافتراضي، مما يحافظ على التوافق مع البيئات التي لا تتوفر فيها WebSockets أصلية.

المقايضات والتحذيرات

يضيف التبديل بين وسائل النقل خطوة تشغيلية صغيرة: إدارة منفذ إضافي والتأكد من عدم تعارضه مع الخدمات الأخرى. نظرًا لأن uWebSockets.js هو وحدة أصلية (native module)، فإنه يجلب الاعتبارات المعتادة للتبعيات الثنائية (binary dependencies) — حيث يجب توفر أدوات البناء (build tools) على مضيف النشر، وسيتعين اختبار أي تحديثات مستقبلية للمكتبة مقابل الكود المصدري للتطبيق.

ما الخطوة التالية لطبقة النقل في Meteor

من خلال توفير حدود واضحة، يدعو Meteor الآن المجتمع لتجربة وسائل نقل بديلة — سواء لمتطلبات أمنية متخصصة، أو توسيعات بروتوكول مخصصة، أو مزيد من ضبط الأداء. وسيشير مدى سرعة ظهور تطبيقات من جهات خارجية إلى ما إذا كان هذا النموذج القابل للتوصيل (pluggable model) سيصبح جزءاً دائماً من بنية Meteor.

الخلاصة: تتيح لك وسيلة نقل DDP القابلة للتوصيل في Meteor 3.5 استبدال مكدس SockJS القديم بـ uWebSockets.js بأمر واحد، مما يوفر معدل معالجة أعلى بمقدار يصل إلى 1.6 ضعف وتوفيراً ملموساً في الموارد للتطبيقات الكثيفة بأسلوب RPC، مع إبقاء الإعداد الحالي دون تغيير لأعباء العمل التي لا تحتاج إلى هذا التعزيز.