Discourse における JS パフォーマンスの変化を測定するために、Google の「tachometer」を使用

Discourse のコア/プラグイン/テーマでクライアントサイドの作業を行う際は、パフォーマンスへの影響を考慮することが重要です。Google の「Tachometer」プロジェクトは、統計的に厳密なベンチマークツールを提供しており、変更の影響を明確に測定するために使用できます。

基本的に、このツールは URL のリストを取得し、それらを「ラウンドロビン」方式で読み込みます。各ページ読み込み時にいくつかのパフォーマンス測定値を取得し、数百〜数千回の反復後に比較表を生成します。

この「ラウンドロビン」アプローチの利点は、外部要因が測定結果に与える影響を軽減できる点です。

ステップ 1: performance.measure() の追加

このアプローチは、テスト内容によって異なりますが、根本的には Tachometer が読み取るための performance.measure() 値を導入する必要があります。

Discourse の起動から描画までの時間を測定したい場合は、組み込みの「discourse-init-to-paint」測定値を使用できます。それ以外の場合は、独自の performance.measure を導入して使用します。

ブラウザの開発者ツールのパフォーマンスタブで動作確認ができます:

ユーザーの操作(例:メニューの表示)を伴うアクティビティを測定したい場合は、イニシャライザーに以下のようなコードを追加し、ページ読み込みから 1 秒後にボタンをクリックさせることができます:

setTimeout(() => document.querySelector(".my-button").click(), 1000);

ステップ 2: テスト用 URL の特定

まず、Ember アセットをプロダクションモードでビルドしていることを確認してください。これは、EMBER_ENV=production を指定してサーバーを起動することで実現できます。

2 つの異なる URL を取得するには、主に 2 つのアプローチがあります。

変更が小さく、機能フラグで簡単に切り替え可能な場合は、URL クエリパラメータに基づいて機能を切り替えるロジックを追加できます。その場合、2 つの URL は以下のようになります:

http://localhost:3000?flag=before
http://localhost:3000?flag=after

変更が大きすぎてこの方法が使えない場合は、Discourse を別のディレクトリにクローンし、2 つ目の Rails インスタンスを起動します。

EMBER_ENV=production UNICORN_PORT=3001 bin/dev

この場合、2 つの URL は以下のようになります:

http://localhost:3000
http://localhost:3001

このアプローチを採用する場合は、アプリの両方のコピーで、このガイドのステップ 1 で導入したパフォーマンステレメトリが機能していることを確認してください。

ステップ 3: Tachometer の設定

以下は、各ターゲットから 300 サンプルを取得する私の bench.json ファイルです:

{
  "timeout": 5,
  "sampleSize": 300,
  "benchmarks": [
    {
      "measurement": {
        "mode": "performance",
        "entryName": "discourse-init-to-paint"
      },
      "expand": [
        {
          "url": "http://localhost:3000",
          "name": "before"
        },
        {
          "url": "http://localhost:3001",
          "name": "after"
        }
      ]
    }
  ]
}

ステップ 4: ベンチマークの実行

ノイズを減らすために、ワークステーション上の無関係な活動を停止し、以下のようなコマンドでベンチマークを開始します:

npx tachometer@latest --config ./bench.json

完了すると、before/after のパフォーマンス比較が表示されます。

注意点

このような実験では、制限事項を考慮することが重要です。例えば:

  • 開発ワークステーションでのパフォーマンスの差が、他のブラウザやデバイスにそのまま反映されるとは限りません

  • Ember-CLI プロキシを介した Discourse の起動プロセスは、本番環境とは完全に一致しません。構造的な変更(例:フレームワークのアップデート)を行う場合、これは重要になる可能性があります

  • パフォーマンスはアプリケーションの状態(例:描画されるトピックの数)によって変動することが多いため、他の環境で完全に再現できない結果になる可能性があります


このドキュメントはバージョン管理されています。変更は GitHub で提案してください。

「いいね!」 17