Meteor 3.5では、単一の環境変数を設定するだけで、SockJSからuWebSockets.jsへ切り替えることが可能になりました。これにより、メソッド呼び出しを多用するアプリケーションにおいて、CPU、RAM、およびガベージコレクションのコストを大幅に削減できることが期待されます。

この変更が重要である理由

Meteorはリリース以来、すべてのDDP（Distributed Data Protocol）メッセージをSockJS経由でルーティングしてきました。SockJSは、あらゆる環境で動作するJavaScriptのフォールバックですが、純粋な速度を追求して設計されたものではありません。今回のリリースではトランスポート層が分離され、DDPの要件に準拠するあらゆるWebSocket実装を受け入れられるプラグインポイントが公開されました。起動時に DDP_TRANSPORT=uws を設定することで、デフォルトが、高いスループットで知られるC/C++ベースのサーバーであるuWebSockets.jsに置き換わります。

パフォーマンスの観点

リリースに同梱されたベンチマークでは、以下の結果が示されています：

  • CPU使用率が9%低下
  • RAM消費量が11%低下
  • ガベージコレクションの停止時間が26%削減
  • マイクロベンチマークにおけるスループットが1.6倍向上

これらの改善は、アプリケーションがRPCスタイルのメソッド呼び出しを多く行う場合に顕著に現れます。トランスポート自体がボトルネックになるのは、アプリケーションのビジネスロジックが最適化された後であるため、この切り替えはサーバーコストの直接的な削減につながります。

今すぐ試す方法

別途バイナリを用意する必要はありません。Meteor 3.5があれば十分です。アプリを次のように実行してください：

DDP_TRANSPORT=uws meteor run

uWebSockets.jsサーバーは独自のポート（デフォルトは5001）で待機します。複数のMeteorインスタンスを同じホストで共有する場合は、衝突を避けるために METEOR_SETTINGS を介して、それぞれに異なる uws.port を割り当てる必要があります。

メリットを受ける層と、あまり変化を感じられない層

  • RPC主体のワークロード – リクエストごとに多くのメソッドを呼び出すサービスは、CPUサイクルとメモリを節約でき、スケーリングの負荷を軽減できます。
  • Pub/Sub中心のアプリ – パブリッシュ/サブスクライブ（Pub/Sub）パターンにおけるレイテンシの大部分は、トランスポートではなくデータの差分計算（data-diff calculations）に起因するため、速度向上は限定的です。

この変更はオプトイン形式です。SockJSは引き続きデフォルトとして維持されるため、ネイティブのWebSocketが利用できない環境との互換性も保たれます。

トレードオフと注意点

トランスポートを切り替えるには、追加のポート管理や他のサービスとの衝突回避といった、わずかな運用上のステップが加わります。uWebSockets.jsはネイティブモジュールであるため、バイナリ依存関係に関する通常の考慮事項が生じます。つまり、デプロイ先のホストにビルドツールが必要であり、ライブラリの将来的なアップデートの際には、アプリケーションのコードベースに対してテストを行う必要があります。

Meteorのトランスポート層の今後

明確な境界を公開したことで、Meteorはコミュニティに対し、特殊なセキュリティ要件、カスタムプロトコルの拡張、あるいはさらなるパフォーマンスチューニングなど、代替トランスポートの実験を促しています。サードパーティによる実装がどれほど迅速に登場するかを見守ることで、このプラグイン可能なモデルがMeteorのアーキテクチャの永続的な一部となるかどうかが分かります。

まとめ: Meteor 3.5のプラグイン可能なDDPトランスポートを使用すれば、単一のコマンドでレガシーなSockJSスタックをuWebSockets.jsに置き換えることができます。これにより、RPC集約型のアプリケーションにおいて最大1.6倍のスループット向上と目に見えるリソース節約を実現しつつ、ブーストを必要としないワークロードについては既存の設定をそのまま維持できます。