WebStreamsを10倍高速化するためにラルフ・ウィガム方式を採用

今年初めにNext.jsのサーバーレンダリングのプロファイリングを開始したとき、フレームグラフに一つの要素が繰り返し現れました：WebStreamsです。それらの中で実行されるアプリケーションコードではなく、ストリームそのものです。Promiseチェーン、チャンクごとのオブジェクト割り当て、マイクロタスクキューのホップです。Theo Browneのサーバーレンダリングベンチマークがフレームワークのオーバーヘッドにどれだけの計算時間が費やされているかを明らかにした後、私たちはその時間が実際にどこで消費されているかを調べ始めました。その多くはストリームの中にありました。 WebStreamsには信じられないほど完全なテストスイートがあり、それが純粋にテスト駆動およびベンチマーク駆動の方法でAIベースの再実装を行うのに最適な候補となっています。この記事は、私たちが行ったパフォーマンス作業、学んだこと、そしてこの作業がMatteo CollinaのアップストリームPRを通じてすでにNode.js自体に取り込まれつつある方法についてです。 問題 Node.jsには2つのストリーミングAPIがあります。古いもの（stream.Readable、stream.Writable、stream.Transform）は10年以上前から存在し、高度に最適化されています。データはC++内部を通過します。背圧はブール値です。パイピングは単一の関数呼び出しです。 新しいものはWHATWG Streams APIです：ReadableStream、WritableStream、TransformStream。これはウェブ標準です。これはfetch()のレスポンスボディ、CompressionStream、TextDecoderStream、そしてますますNext.jsやReactのようなフレームワークでのサーバーサイドレンダリングを動かしています。 ウェブ標準は収束すべき正しいAPIです。しかしサーバー上では、必要以上に遅いのです。 その理由を理解するために、Node.jsでネイティブWebStreamに対してreader.read()を呼び出したときに何が起こるかを考えてみてください。データがすでにバッファにある場合でも： ReadableStreamDefaultReadRequestオブジェクトが3つのコールバックスロットで割り当てられる リクエストがストリームの内部キューにエンキューされる 新しいPromiseが割り当てられて返される 解決はマイクロタスクキューを通過する これは、すでに存在していたデータを返すために4つの割り当てとマイクロタスクホップです。さて、これをレンダリングパイプラインのすべての変換を流れるすべてのチャンクで乗算してみてください。 あるいはpipeTo()を考えてみてください。各チャンクは完全なPromiseチェーンを通過します：読み取り、書き込み、背圧チェック、繰り返し。{value, done}結果オブジェクトが読み取りごとに割り当てられます。エラー伝播は追加のPromiseブランチを作成します。 これらは間違っていません。これらの保証は、ストリームがセキュリティ境界を越え、キャンセルセマンティクスが厳密である必要があり、パイプの両端を制御できないブラウザでは重要です。しかしサーバー上では、React Server Componentsを1KBチャンクで3つの変換を通してパイピングしているとき、コストは積み上がります。 私たちはネイティブWebStreamのpipeThroughを1KBチャンクで630 MB/sでベンチマークしました。同じパススルー変換でのNode.js pipeline()：〜7,900 MB/s。これは12倍の差であり、その違いはほとんど完全にPromiseとオブジェクト割り当てのオーバーヘッドです。 私たちが構築したもの 私たちはfast-webstreamsというライブラリに取り組んでいます。これはWHATWGのReadableStream、WritableStream、TransformStream APIを内部でNode.jsストリームによってバックアップして実装しています。同じAPI、同じエラー伝播、同じ仕様準拠です。一般的なケースではオーバーヘッドが除去されています。 核となるアイデアは、実際に行っていることに応じて異なる高速パスを通じて操作をルーティングすることです： 高速ストリーム間でパイプするとき：ゼロPromise これが最大の成果です。高速ストリーム間でpipeThroughとpipeToをチェーンするとき、ライブラリはすぐにパイピングを開始しません。代わりに、アップストリームリンクを記録します： source → transform1 → transform2 → ... チェーンの最後でpipeTo()が呼び出されると、アップストリームを辿り、基礎となるNode.jsストリームオブジェクトを収集し、単一のpipeline()呼び出しを発行します。一つの関数呼び出し。チャンクごとのゼロPromise。データはNodeの最適化されたC++パスを流れます。 結果：〜6,200 MB/s。これはネイティブWebStreamsより〜10倍高速で、生のNode.js pipelineパフォーマンスに近いです。 チェーン内のいずれかのストリームが高速ストリームでない場合（例えばネイティブのCompressionStream）、ライブラリはネイティブのpipeThroughまたは仕様準拠のpipeTo実装にフォールバックします。 チャンクごとに読み取るとき：同期的解決 reader.read()を呼び出すとき、ライブラリはnodeReadable.read()を同期的に試みます。データがあれば、Promise.resolve({value, done})が得られます。イベントループの往復はありません。リクエストオブジェクトの割り当てはありません。バッファが空のときだけリスナーを登録し、保留中のPromiseを返します。 結果：〜12,400 MB/s、またはネイティブより3.7倍高速です。 React Flightパターン：差が最大のところ これはNext.jsにとって最も重要なものです。React Server Componentsは特定のバイトストリームパターンを使用します：type: 'bytes'でReadableStreamを作成し、start()でコントローラーをキャプチャし、レンダリングが生成するときに外部からチャンクをエンキューします。 ネイティブWebStreams：〜110 MB/s。fast-webstreams：〜1,600 MB/s。これは本番サーバーレンダリングで使用される正確なパターンで14.6倍高速です。 速度は、バイトストリーム用にNode.jsのReadableを置き換えるために書いた最小限の配列ベースのバッファであるLiteReadableから来ています。これはEventEmitterの代わりに直接コールバックディスパッチを使用し、プルベースの需要とBYOBリーダーをサポートし、構築ごとに約5マイクロ秒少ないコストです。これはReact Flightがリクエストごとに数百のバイトストリームを作成するときに重要です。 Fetchレスポンスボディ：自分で構築しないストリーム 上記の例はすべてnew ReadableStream(...)で始まります。しかしサーバー上では、ほとんどのストリームはそのようには始まりません。それらはfetch()から始まります。レスポンスボディはNode.jsのHTTPレイヤーが所有するネイティブバイトストリームです。これを入れ替えることはできません。 これはサーバーサイドレンダリングで一般的なパターンです：アップストリームサービスからデータをフェッチし、レスポンスを1つ以上の変換を通してパイプし、結果をクライアントに転送します。 ネイティブWebStreamsでは、このチェーンの各ホップがチャンクごとの完全なPromiseコストを支払います。3つの変換はチャンクごとに約6-9のPromiseを意味します。1KBチャンクでは、〜260 MB/sになります。 ライブラリは遅延解決を通じてこれを処理します。patchGlobalWebStreams()がアクティブなとき、Response.prototype.bodyはネイティブバイトストリームをラップする軽量な高速シェルを返します。pipeThrough()を呼び出しても、すぐにパイピングを開始しません。単にリンクを記録するだけです。最後でpipeTo()またはgetReader()が呼び出されたときだけ、ライブラリは完全なチェーンを解決します：ネイティブリーダーから変換ホップ用のNode.js pipeline()への単一のブリッジを作成し、その後バッファリングされた出力から同期的に読み取りを提供します。 コストモデル：ネイティブ境界でデータを取り込むための1つのPromise。変換チェーンを通じてのゼロPromise。出力での同期読み取り。 結果：〜830 MB/s、または3変換フェッチパターンでネイティブより3.2倍高速です。変換なしの単純なレスポンス転送では、2.0倍高速です（850 vs 430 MB/s）。 ベンチマーク すべての数値はNode.js v22での1KBチャンクでのMB/sのスループットです。高いほど良いです。 コア操作 操作 Node.jsストリーム fast ネイティブ fast vs ネイティブ 読み取りループ 26,400 12,400 3,300 3.7倍 書き込みループ 26,500 5,500 2,300 2.4倍 pipeThrough 7,900 6,200 630 9.8倍 pipeTo 14,000 2,500 1,400 1.8倍 for-await-of — 4,100 3,000 1.4倍 変換チェーン チャンクごとのPromiseオーバーヘッドはチェーンの深さとともに複合します： 深さ fast ネイティブ fast vs ネイティブ 3変換 2,900 300 9.7倍 8変換 1,000 115 8.7倍 バイトストリーム パターン fast ネイティブ fast vs ネイティブ start + enqueue (React Flight) 1,600 110 14.6倍 バイト読み取りループ 1,400 1,400 1.0倍 バイトtee 1,200 750 1.6倍 レスポンスボディパターン パターン fast ネイティブ fast vs ネイティブ Response.text() 900 910 1.0倍 レスポンス転送 850 430 2.0倍 フェッチ → 3変換 830 260 3.2倍 ストリーム構築 ストリームの作成も高速であり、これは短命ストリームにとって重要です： タイプ fast ネイティブ fast vs ネイティブ ReadableStream 2,100 980 2.1倍 WritableStream 1,300 440 3.0倍 TransformStream 470 220 2.1倍 仕様準拠 fast-webstreamsは1,116のWeb Platform Testsのうち1,100を通過します。Node.jsのネイティブ実装は1,099を通過します。残りの16の失敗は、ネイティブと共有されているもの（未実装のtype: 'owning'転送モードなど）か、実際のアプリケーションに影響を与えないアーキテクチャの違いです。 私たちがこれをどのように展開しているか ライブラリはグローバルなReadableStream、WritableStream、TransformStreamコンストラクターをパッチできます： パッチはまたResponse.prototype.bodyをインターセプトして、ネイティブフェッチレスポンスボディを高速ストリームシェルでラップするので、fetch() → pipeThrough() → pipeTo()チェーンは自動的にパイプライン高速パスにヒットします。 Vercelでは、私たちはこれをフリート全体に展開することを検討しています。慎重かつ段階的に行います。ストリーミングプリミティブはリクエスト処理、レスポンスレンダリング、圧縮の基礎にあります。私たちは差が最大のパターンから始めます：React Server Componentストリーミング、レスポンスボディ転送、マルチ変換チェーンです。さらに拡大する前に本番環境で測定します。 正しい修正はアップストリームに ユーザーランドライブラリはここでの長期的な答えであるべきではありません。正しい修正はNode.js自体にあります。 作業はすでに進行中です。Xでの会話の後、Matteo Collinaはnodejs/node#61807、「stream: add fast paths for webstreams read and pipeTo」を提出しました。このPRはこのプロジェクトからの2つのアイデアを直接Node.jsのネイティブWebStreamsに適用します： read()高速パス：データがすでにバッファリングされているとき、ReadableStreamDefaultReadRequestオブジェクトを作成せずに直接解決済みPromiseを返します。これは仕様準拠です。なぜならread()はどちらにせよPromiseを返し、解決済みPromiseもマイクロタスクキューでコールバックを実行するからです。 pipeTo()バッチ読み取り：データがバッファリングされているとき、チャンクごとのリクエストオブジェクトを作成せずにコントローラーキューから複数の読み取りをバッチ処理します。背圧は各書き込み後にdesiredSizeをチェックすることで尊重されます。 PRはバッファリングされた読み取りで〜17-20%高速、pipeToで〜11%高速を示しています。これらの改善はすべてのNode.jsユーザーに無料で利益をもたらします。インストールするライブラリなし、パッチなし、リスクなしです。 James SnellのNode.jsパフォーマンス問題 #134は、さらにいくつかの改善の機会を概説しています：内部ソースストリームのためのC++レベルでのパイピング、遅延バッファリング、WritableStreamアダプターでの二重バッファリングの排除などです。これらのそれぞれが、さらにギャップを埋める可能性があります。 私たちはアイデアを上流に貢献し続けます。目標はfast-webstreamsが永遠に存在することではありません。目標は、WebStreamsがそれ自体で十分に高速であり、fast-webstreamsが必要なくなることです。 私たちが苦労して学んだこと 仕様は見た目よりも賢いです。私たちは多くの近道を試しました。ほとんどすべての試みがWeb Platform Testに失敗し、テストは通常正しかったのです。ReadableStreamDefaultReadRequestパターン、読み込みごとのPromise設計、注意深いエラー伝播：これらは、読み取り中のキャンセル、ロックされたストリームを介したエラー識別、thenableインターセプションが実際のコードが遭遇する現実のエッジケースであるために存在しています。 Promise.resolve(obj)は常にthenableをチェックします。これは避けられない言語レベルの動作です。解決するオブジェクトが.thenプロパティを持っている場合、Promise機構はそれを呼び出します。一部のWPTテストは意図的に読み取り結果に.thenを配置し、ストリームがそれを正しく処理することを検証します。私たちは、ホットパスで{value, done}オブジェクトが作成される場所に非常に注意する必要がありました。 Node.js pipeline()はWHATWG pipeToの代わりにはなりません。私たちはすべてのパイピングにpipeline()を使用することを望みました。それは72のWPT失敗を引き起こします。エラー伝播、ストリームロック、キャンセルセマンティクスは根本的に異なります。pipeline()は、私たちがチェーン全体を制御している場合にのみ安全です。それが私たちが上流リンクを収集し、完全なfast-streamチェーンに対してのみそれを使用する理由です。 Reflect.apply、.call()ではありません。WPTスイートはFunction.prototype.callをモンキーパッチし、実装がユーザー提供のコールバックを呼び出すためにそれを使用しないことを検証します。Reflect.applyが唯一安全な方法です。これは実際の仕様要件です。 私たちはfast-webstreamsの大部分をAIで構築しました それを可能にした2つのことがあります： 驚くべきWeb Platform Testsは、1,116のテストを「何かを壊したか？」に対する即座の機械検証可能な答えとして提供しました。そして私たちは早期にベンチマークスイートを構築したので、各変更が実際にスループットを向上させたかどうかを測定できました。開発ループは次の通りでした：最適化を実装し、WPTスイートを実行し、ベンチマークを実行する。テストが失敗したとき、私たちはどの仕様不変条件に違反したかを知りました。ベンチマークが向上しなかったとき、私たちは元に戻しました。 WHATWG Streams仕様は長くて密度が高いです。興味深い最適化の機会は、仕様が要求することと現在の実装が行うことの間のギャップにあります。read()はPromiseを返さなければなりませんが、データがバッファリングされているときにそのPromiseがすでに解決済みであってはならないとは何も言っていません。その種の観察は、AIにアルゴリズムステップを分析させ、観測可能な動作をより少ない割り当てで維持できる場所を特定させることができるとき、直接的に行えます。 試してみてください fast-webstreamsはexperimental-fast-webstreamsとしてnpmで利用可能です。「experimental」という接頭辞は意図的です。私たちは正確性に自信を持っていますが、これは活発に開発が行われている分野です。 もしあなたがサーバーサイドJavaScriptフレームワークやランタイムを構築していてWebStreamsのパフォーマンス限界に直面しているなら、私たちはあなたからの連絡を歓迎します。そしてもしNode.js自体でWebStreamsを改善することに興味があるなら、MatteoのPRは始めるのに最適な場所です。 続きを読む

WebStreamsを10倍高速化するためにラルフ・ウィガム方式を採用

背景や根拠まで確認しますか？

調べる

選ぶ

サイト

背景や根拠まで確認しますか？

ニュースの次に確認する

調べる

選ぶ

サイト