Meteor 3.5 به توسعه‌دهندگان این امکان را می‌دهد که با استفاده از تنها یک متغیر محیطی (environment variable)، SockJS را به نفع uWebSockets.js کنار بگذارند؛ این تغییر وعده کاهش محسوس هزینه‌های CPU، RAM و مدیریت حافظه (garbage-collection) را برای برنامه‌هایی که به شدت بر فراخوانی متدها (method calls) متکی هستند، می‌دهد.

چرا این تغییر اهمیت دارد

از زمان عرضه، Meteor هر پیام DDP (Distributed Data Protocol) را از طریق SockJS هدایت می‌کرد؛ یک جایگزین (fallback) مبتنی بر JavaScript که در همه جا کار می‌کند اما هرگز برای سرعت خالص طراحی نشده بود. نسخه جدید، لایه انتقال (transport layer) را از هم جدا کرده و یک نقطه اتصال (plug-in point) ایجاد می‌کند که هر پیاده‌سازی WebSocket مطابق با انتظارات DDP را می‌پذیرد. تنظیم DDP_TRANSPORT=uws هنگام اجرا، جایگزین پیش‌فرض را با uWebSockets.js عوض می‌کند؛ سروری مبتنی بر C/C++ که به توان عملیاتی (throughput) بالا مشهور است.

جنبه عملکرد (Performance)

بنچمارک‌های ارائه شده همراه با این نسخه نشان می‌دهند:

  • کاهش ۹ درصدی مصرف CPU
  • کاهش ۱۱ درصدی مصرف RAM
  • کاهش ۲۶ درصدی زمان توقف Garbage-collection
  • افزایش ۱.۶ برابری Throughput در ریز-بنچمارک‌ها (micro-benchmarks)

این بهبودها زمانی مشاهده می‌شوند که یک اپلیکیشن فراخوانی‌های متد زیادی به سبک RPC انجام دهد. لایه انتقال تنها زمانی به گلوگاه (bottleneck) تبدیل می‌شود که منطق تجاری (business logic) اپلیکیشن بهینه‌سازی شده باشد، بنابراین این تغییر می‌تواند مستقیماً به کاهش هزینه‌های سرور منجر شود.

چگونه همین امروز آن را امتحان کنید

به فایل باینری جداگانه‌ای نیاز نیست—فقط Meteor 3.5 کافی است. برنامه را با دستور زیر اجرا کنید:

DDP_TRANSPORT=uws meteor run

سرور uWebSockets.js روی پورت مخصوص به خود (پیش‌فرض ۵۰۰۱) گوش می‌دهد. زمانی که چندین نمونه (instance) از Meteor یک میزبان (host) مشترک دارند، برای جلوگیری از تداخل، باید برای هر کدام یک uws.port متمایز از طریق METEOR_SETTINGS تعیین شود.

چه کسانی سود می‌برند و چه کسانی ممکن است تفاوت چندانی حس نکنند

  • بار کاری سنگین از نوع RPC – سرویس‌هایی که در هر درخواست متدهای زیادی را فراخوانی می‌کنند، از صرفه‌جویی در چرخه‌های CPU و حافظه بهره‌مند شده و فشار مقیاس‌پذیری (scaling) کاهش می‌یابد.
  • اپلیکیشن‌های مبتنی بر Pub/Sub – بیشتر تأخیر (latency) در الگوهای انتشار/اشتراک (publish/subscribe) ناشی از محاسبات تفاوت داده‌ها (data-diff) است و نه لایه انتقال، بنابراین افزایش سرعت در این حالت ناچیز خواهد بود.

این تغییر اختیاری است؛ SockJS همچنان به عنوان پیش‌فرض باقی می‌ماند تا سازگاری با محیط‌هایی که WebSockets بومی در آن‌ها در دسترس نیست، حفظ شود.

ملاحظات و هشدارها

تغییر لایه انتقال یک مرحله عملیاتی کوچک اضافه می‌کند: مدیریت یک پورت اضافی و اطمینان از اینکه با سایر سرویس‌ها تداخل نداشته باشد. از آنجایی که uWebSockets.js یک ماژول بومی (native module) است، ملاحظات معمول مربوط به وابستگی‌های باینری را به همراه دارد—ابزارهای ساخت (build tools) باید روی میزبان استقرار (deployment host) موجود باشند و هرگونه به‌روزرسانی آتی کتابخانه باید در برابر کد برنامه آزمایش شود.

گام بعدی برای لایه انتقال Meteor چیست

Meteor با ایجاد یک مرز مشخص، اکنون از جامعه کاربری دعوت می‌کند تا با لایه‌های انتقال جایگزین آزمایش کند—خواه برای نیازهای امنیتی خاص باشد، خواه برای توسعه پروتکل‌های سفارشی یا تنظیمات بیشتر عملکرد. مشاهده سرعت ظهور پیاده‌سازی‌های شخص ثالث نشان خواهد داد که آیا این مدل پلاگین‌محور (pluggable) به بخشی ماندگار از معماری Meteor تبدیل خواهد شد یا خیر.

خلاصه: لایه انتقال DDP پلاگین‌محور در Meteor 3.5 به شما اجازه می‌دهد تا با یک دستور واحد، پشته (stack) قدیمی SockJS را با uWebSockets.js جایگزین کنید؛ این کار تا ۱.۶ برابر افزایش Throughput و صرفه‌جویی قابل توجه در منابع را برای اپلیکیشن‌های متمرکز بر RPC فراهم می‌کند، در حالی که تنظیمات موجود برای بار کاری‌هایی که نیازی به این افزایش سرعت ندارند، بدون تغییر باقی می‌ماند.