Googleの「tachometer」でDiscourseのJSパフォーマンス変化を測定

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の2番目のコピーを起動できます。

EMBER_ENV=production UNICORN_PORT=3001 bin/dev

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

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

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

ステップ 3: Tachometerの設定

以下は私の bench.json ファイルです。これは各ターゲットに対して300回のサンプルを取得します:

{
  "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

完了すると、変更前/変更後パフォーマンスの比較が表示されるはずです。

注意点

こうした実験と同様に、限界を考慮することが重要です。例えば:

  • 開発用ワークステーションでのパフォーマンスの違いは、他のブラウザ/デバイスに直接反映されない場合があります。

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

  • パフォーマンスはアプリケーションの状態(例: レンダリングされるトピックの数)に基づいて変化するため、結果は他の環境では完全に再現できない可能性があります。


このドキュメントはバージョン管理されています - 変更提案は github でどうぞ。

「いいね!」 17