React SSR のパフォーマンスをベンチマークする方法
コンテンツ検証、ロード、p95 レイテンシー、応答ごとの CPU、メモリおよびブラウザーのチェックを備えた、再現可能な React SSR ベンチマークを構築します。
PRNextPRNext 耐久テスト: 2 時間と 1,738 編集
作者 PRNext
PRNext高速編集は便利です。数百回の変更後も信頼性を維持できる開発セッションも同様に重要です。その長いワークフローを調査するために、凍結された PRNext 0.1.17 開発スナップショットを 2 時間実行しました。
目的は、失われた状態、壊れた回復、中断されたストリーム、および制御されていないリソースの増加を見つけることでした。これは、Next.js に対する新たな速度比較ではなく、定義されたワークロードを使用した安定性テストでした。
実際の編集と実際のブラウザを使用したセッション
実行は 7,201 秒続き、1,738 JavaScript と CSS 編集が適用されました。 4 つの Chromium タブは、App Router および Pages Router フィクスチャを実行しました。意図的な構文エラーにより、回復をテストするためにシーケンスが 28 回中断されました。
ブラウザーのチェックでは、HTTP 200 応答が十分であるとは見なされず、ドキュメント マーカーとコンポーネントの状態が保持されました。ワークロードでは、ストリーミングされた応答の順序と、応答後にキャッシュにアクセスするバックグラウンド作業もチェックしました。
このシナリオでは、175 サーバー アクションの呼び出しも実行されました。各応答は、単にトランスポート層で成功するのではなく、予想されるアプリケーション世代に属している必要があります。構文回復では、ソースの修復後に、無関係なタブの状態をリセットせずに、ページを使用可能な出力に復元する必要がありました。
ドキュメントとコンポーネントの状態が保存された 4 つのブラウザ タブ。 28 は、強制的な構文エラーの後に回復します。 174 ストリーミングおよび 174 バックグラウンド/キャッシュ チェック。ブラウザ ハーネスによって記録されたページ エラーはゼロです。
1 つのプロセスだけでなくサービス ツリーを測定する
サンプルされたプロセス ツリーには、Node.js、esbuild、およびネイティブ Rust サービスが含まれていました。そのピーク比例セット サイズは 536.51 MiB でした。定義された定常状態ウィンドウ間の成長は 59.05 MiB で、サンプリングされたプロセスは最大 10 個でした。
これらの測定値はテストのリソース予算内に収まりました。これらは、この器具、サンプリング方法、およびマシンに関する観察です。これらは普遍的なメモリ要件でも、リークが存在しないことの証明でもありません。
ネイティブ サービスだけをカウントすると、JavaScript ワーカーとコンパイラ ヘルパーのコストが隠れてしまいます。比例セット サイズも、常駐セットの読み取り値の合計とは異なり、共有メモリを考慮します。したがって、別の実行をこれらの数値と比較すると、ピークおよび定常状態の成長はサンプリング方法に属します。
テストされたスナップショットについて明示的にする
2 時間の実行では、最後の .mts/.cts フレームワーク境界ガードが追加される前に、凍結されたスナップショットが使用されました。編集されたソースは JavaScript と JSX でした。最後のガードは、個別の回帰、パッケージング、プラットフォームのチェックに加えて、より短い 4 タブのスモーク ランを受けました。
補助ファイルシステム保持モニターにも 25-minute サンプリング ギャップがありました。プライマリブラウザとメモリのチェックは続行されました。レポート内でこれらの制限を維持することは、測定されなかった中断のない結果を提示することよりも重要です。
スナップショット間の区別は、セキュリティに配慮した修正にとって重要です。後者の境界ガードには、独自の通過回帰とライフサイクルの証拠がありますが、これらのチェックでは 2 時間実行されたソースを遡って変更することはできません。両方の記録を保持すると、それぞれの結果が何を確立しているかを正確に理解できるようになります。
結果から得られるもの
この Linux x64 ワークロードでは、繰り返しの編集、リカバリ、およびリソースの予算が持ちこたえられました。 Windows x64 は、個別のパッケージ化、ライフサイクル、およびブラウザーの検証を受けました。ブラウザーの個別のリグレッションでは、匿名のデフォルト コンポーネントと新しいサーバー アクションの応答の状態の保存も検証されます。
これは macOS や ARM64 の検証ではなく、個々のアプリケーションのテストに代わるものでもありません。また、Next.js に対する新たな性能上の優位性を示すものでもありません。それぞれ別の検証と測定が必要です。
アプリケーション固有のチェックの場合は、いくつかの代表的なページを開いたままにし、編集する前にそれらのページを操作し、意図的な構文エラーを含めてから修復します。ブラウザーのエラーとサービス プロセス ツリーをビルド時間とともに観察します。これは、セッション全体を最速の更新まで短縮するのではなく、作業の継続性をテストします。