Googles „Tachometer“ zur Messung von JS-Performance-Änderungen in Discourse

Dokumentation Entwicklerhandbücher
1

Bei der Arbeit an Client-seitigen Aufgaben in Discourse Core/Plugins/Themes ist es wichtig, die Auswirkungen auf die Leistung zu berücksichtigen. Googles Projekt ‘Tachometer’ stellt ein statistisch rigoroses Benchmarking-Tool bereit, mit dem wir die Wirkung von Änderungen definitiv messen können.

Im Wesentlichen lädt dieses Tool eine Liste von URLs in einem ‘Round-Robin’-Verfahren. Für jeden Seitenaufruf werden einige Leistungsmessungen vorgenommen. Nach Hunderten oder Tausenden von Iterationen wird eine Vergleichstabelle erstellt.

Die Schönheit dieses ‘Round-Robin’-Ansatzes besteht darin, dass er hilft, den Einfluss externer Faktoren auf die Messungen zu reduzieren.

Schritt 1: performance.measure() hinzufügen

Der Ansatz hängt davon ab, was du testest. Grundsätzlich gilt: Du musst einen performance.measure()-Wert einführen, den Tachometer lesen kann.

Wenn du die Zeit messen möchtest, die Discourse zum Starten und Rendern benötigt, kannst du die eingebaute Messung “discourse-init-to-paint” verwenden. Für alles andere kannst du deine eigene performance.measure-Messung einführen und diese verwenden.

Du kannst überprüfen, ob es funktioniert, indem du den Leistungstab in den Entwickler-Tools deines Browsers verwendest:

SCR-20240529-rlhj
SCR-20240529-rlhj1234×176 5.86 KB

Wenn du eine Aktivität messen möchtest, die eine Benutzerinteraktion erfordert (z. B. das Öffnen eines Menüs), kannst du dies erreichen, indem du in einem Initializer etwas wie Folgendes hinzufügst, um die Schaltfläche 1 Sekunde nach dem Laden der Seite zu klicken:

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

Schritt 2: URLs für Tests identifizieren

Stelle zunächst sicher, dass du die Ember-Assets im Produktionsmodus baust. Dies kann erreicht werden, indem du den Server mit EMBER_ENV=production startest.

Um zwei verschiedene URLs zu erhalten, gibt es zwei Hauptansätze:

Wenn deine Änderung klein genug ist, um leicht per Feature-Flag gesteuert zu werden, kannst du Logik hinzufügen, um sie basierend auf einem URL-Abfrageparameter umzuschalten. Dann könnten deine beiden URLs lauten:

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

Wenn die Änderung dafür zu groß ist, kannst du einen Git-Worktree erstellen und daraus eine zweite Kopie von Rails auf einem anderen Port starten:

git worktree add ../discourse-after my-branch
cd ../discourse-after
bundle install
pnpm install
EMBER_ENV=production UNICORN_PORT=3001 bin/dev

Beide Kopien teilen sich dieselbe Datenbank und Redis, stelle also sicher, dass keiner der Zweige Migrationsdateien enthält, die der andere nicht hat.

Und dann würden deine beiden URLs lauten:

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

Wenn du diesen Ansatz verwendest, stelle sicher, dass beide Kopien der App die Leistungstelemetrie enthalten, die du in Schritt 1 dieses Leitfadens eingeführt hast.

Schritt 3: Tachometer konfigurieren

Das ist meine bench.json-Datei, die 300 Stichproben von jedem Ziel nehmen wird:

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

Schritt 4: Benchmark ausführen

Um Rauschen zu reduzieren, stoppe alle nicht verwandten Aktivitäten auf deinem Arbeitsrechner und starte dann den Benchmark mit einem Befehl wie:

pnpx tachometer --config ./bench.json

Nach Abschluss solltest du einen Vergleich der Leistung vor/nach der Änderung sehen.

image
image1500×412 48.9 KB

Einschränkungen

Wie bei jedem solchen Experiment lohnt es sich, die Einschränkungen zu berücksichtigen. Zum Beispiel:

  • Leistungsunterschiede auf deinem Entwicklungsrechner müssen nicht direkt auf andere Browser/Geräte übertragbar sein.
  • Der Startprozess von Discourse im Entwicklungsmodus ist nicht genau derselbe wie in der Produktion. Bei strukturellen Änderungen (z. B. Framework-Updates) kann dies wichtig sein.
  • Die Leistung variiert oft je nach Anwendungszustand (z. B. die Anzahl der gerenderten Themen), daher sind deine Ergebnisse in anderen Umgebungen möglicherweise nicht exakt reproduzierbar.

Dieses Dokument wird versioniert – Vorschläge für Änderungen auf GitHub.

17 „Gefällt mir“