Использование «тахометра» Google для измерения изменений производительности JS в Discourse

При работе над клиентской частью в ядре Discourse, плагинах или темах важно учитывать влияние на производительность. Проект Google «Tachometer» предоставляет инструмент для статистически строгого бенчмаркинга, который позволяет однозначно оценить эффект от внесённых изменений.

По сути, этот инструмент принимает список URL-адресов и загружает их в режиме «круговой очереди» (round-robin). Для каждой загрузки страницы выполняется измерение производительности. После сотен или тысяч итераций формируется таблица сравнения.

Преимущество подхода «круговой очереди» заключается в том, что он помогает снизить влияние внешних факторов на результаты измерений.

Шаг 1: Добавьте performance.measure()

Подход может различаться в зависимости от того, что именно вы тестируете. Однако фундаментально: вам необходимо внедрить значение performance.measure(), которое сможет считать Tachometer.

Если вы хотите измерить время загрузки и отрисовки Discourse, можно использовать встроенное измерение «discourse-init-to-paint». Для любых других целей вы можете создать собственное performance.measure() и использовать его.

Проверить работоспособность можно через вкладку «Производительность» в инструментах разработчика вашего браузера:

Если вы пытаетесь измерить действие, требующее взаимодействия пользователя (например, открытие меню), это можно реализовать, добавив в инициализатор код, который нажмёт кнопку через 1 секунду после загрузки страницы:

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

Шаг 2: Определите URL-адреса для тестирования

Во-первых, убедитесь, что вы собираете ресурсы Ember в режиме production. Это можно сделать, запустив сервер с переменной окружения EMBER_ENV=production.

Чтобы получить два разных URL-адреса, существует два основных подхода:

Если ваше изменение достаточно незначительное и его легко контролировать через флаги функций, вы можете добавить логику переключения на основе параметра запроса URL. Тогда ваши два URL-адреса могут выглядеть так:

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

Если изменение слишком масштабное для такого подхода, вы можете клонировать Discourse в другую директорию и запустить вторую копию Rails.

EMBER_ENV=production UNICORN_PORT=3001 bin/dev

Тогда ваши два 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

После завершения вы должны увидеть сравнение производительности до и после изменений.

Ограничения

Как и в любых подобных экспериментах, стоит учитывать ограничения. Например:

  • Различия в производительности на вашей рабочей станции могут не соответствовать другим браузерам или устройствам.

  • Процесс загрузки Discourse через прокси Ember-CLI не совсем идентичен процессу в production. При внесении структурных изменений (например, обновлений фреймворка) это может быть важно.

  • Производительность часто зависит от состояния приложения (например, количества отображаемых тем), поэтому ваши результаты могут не воспроизводиться точно в других средах.


Этот документ находится под контролем версий — предлагайте изменения на GitHub.

17 лайков