Meteor 3.5 pozwala programistom zrezygnować z SockJS na rzecz uWebSockets.js za pomocą jednej zmiennej środowiskowej, obiecując wyraźnie niższe zużycie procesora (CPU), pamięci RAM oraz koszty odśmiecania pamięci (garbage collection) dla aplikacji silnie polegających na wywołaniach metod.

Dlaczego ta zmiana jest ważna

Od momentu premiery Meteor przekazywał każdą wiadomość DDP (Distributed Data Protocol) przez SockJS – rozwiązanie typu fallback w JavaScript, które działa wszędzie, ale nigdy nie było projektowane z myślą o surowej szybkości. Nowa wersja rozdziela warstwę transportową, udostępniając punkt wpięcia, który akceptuje dowolną implementację WebSocket zgodną z oczekiwaniami DDP. Ustawienie DDP_TRANSPORT=uws podczas uruchamiania zamienia domyślne rozwiązanie na uWebSockets.js – serwer oparty na C/C++, znany z wysokiej przepustowości.

Aspekt wydajnościowy

Benchmarki dostarczone wraz z wydaniem pokazują:

  • zużycie CPU niższe o 9%
  • zużycie RAM niższe o 11%
  • czas pauzy garbage collection skrócony o 26%
  • przepustowość wyższa 1,6-krotnie w mikrobenchmarkach

Zyski te są widoczne, gdy aplikacja wykonuje wiele wywołań metod w stylu RPC. Sam transport staje się wąskim gardłem dopiero po optymalizacji logiki biznesowej aplikacji, więc zmiana może bezpośrednio przełożyć się na niższe koszty serwera.

Jak wypróbować to już dziś

Nie jest wymagany żaden oddzielny plik binarny — wystarczy Meteor 3.5. Uruchom aplikację za pomocą:

DDP_TRANSPORT=uws meteor run

Serwer uWebSockets.js nasłuchuje na własnym porcie (domyślnie 5001). Gdy wiele instancji Meteor współdzieli jeden host, każdej należy przypisać odrębny uws.port za pomocą METEOR_SETTINGS, aby uniknąć konfliktów.

Kto zyska, a kto może nie zauważyć większej różnicy

  • Obciążenia typu RPC-heavy – usługi wywołujące wiele metod na każde żądanie mogą zaoszczędzić cykle CPU i pamięć, co ułatwi skalowanie.
  • Aplikacje skoncentrowane na Pub/Sub – większość opóźnień w wzorcach publish/subscribe wynika z obliczeń różnic danych (data-diff), a nie z transportu, więc wzrost prędkości jest umiarkowany.

Zmiana jest opcjonalna; SockJS pozostaje domyślnym rozwiązaniem, co zapewnia kompatybilność ze środowiskami, w których natywne WebSockets są niedostępne.

Kompromisy i środki ostrożności

Zmiana transportu dodaje mały krok operacyjny: zarządzanie dodatkowym portem i upewnienie się, że nie koliduje on z innymi usługami. Ponieważ uWebSockets.js jest modułem natywnym, wiąże się to ze standardowymi kwestiami dotyczącymi zależności binarnych — narzędzia budujące muszą znajdować się na hoście wdrożeniowym, a wszelkie przyszłe aktualizacje biblioteki będą wymagały przetestowania pod kątem kodu aplikacji.

Co dalej z warstwą transportową Meteor

Poprzez udostępnienie wyraźnej granicy, Meteor zaprasza społeczność do eksperymentowania z alternatywnymi transportami — czy to ze względu na specjalistyczne wymagania bezpieczeństwa, niestandardowe rozszerzenia protokołów, czy dalsze strojenie wydajności. To, jak szybko pojawią się implementacje firm trzecich, wskaże, czy model plug-in stanie się trwałym elementem architektury Meteor.

Podsumowanie: Opcjonalny transport DDP w Meteor 3.5 pozwala zastąpić starszy stos SockJS przez uWebSockets.js za pomocą jednej komendy, zapewniając do 1,6-krotnie wyższą przepustowość i wymierne oszczędności zasobów dla aplikacji intensywnie korzystających z RPC, przy jednoczesnym zachowaniu dotychczasowej konfiguracji dla obciążeń, które nie wymagają takiego przyspieszenia.