Googles „tachometer“ zur Messung von JS-Leistungsänderungen in Discourse verwenden

Dokumentation Entwicklerhandbücher
1

Wenn Sie an clientseitiger Arbeit in Discourse core/plugins/themes arbeiten, ist es wichtig, die Auswirkungen auf die Leistung zu berücksichtigen. Das Projekt „Tachometer“ von Google bietet ein statistisch fundiertes Benchmarking-Tool, mit dem wir die Auswirkungen von Änderungen eindeutig messen können.

Im Wesentlichen nimmt dieses Tool eine Liste von URLs und lädt sie in einer „Round-Robin“-Methode. Für jeden Seitenaufruf wird eine Leistungs­messung durchgeführt. Nach Hunderten/Tausenden von Iterationen wird eine Vergleichstabelle erstellt.

Der Vorteil dieses „Round-Robin“-Ansatzes besteht darin, dass er dazu beiträgt, den Einfluss externer Faktoren auf die Messungen zu reduzieren.

Schritt 1: performance.measure() hinzufügen

Der Ansatz hier variiert je nachdem, was Sie testen. Aber im Grunde: Sie müssen einen performance.measure()-Wert einführen, den Tachometer lesen kann.

Wenn Sie die Zeit messen möchten, die Discourse zum Starten und Rendern benötigt, können Sie die integrierte Messung „discourse-init-to-paint“ verwenden. Für alles andere können Sie Ihre eigene performance.measure einführen und diese verwenden.

Sie können überprüfen, ob es funktioniert, indem Sie den Tab „Leistung“ in den Entwicklertools Ihres Browsers überprüfen:

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

Wenn Sie eine Aktivität messen möchten, die eine Benutzerinteraktion erfordert (z. B. das Öffnen eines Menüs), könnten Sie dies erreichen, indem Sie in einem Initialisierer etwas Ähnliches wie das Folgende hinzufügen, um die Schaltfläche 1 Sekunde nach dem Laden der Seite anzuklicken:

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

Schritt 2: URLs für den Test identifizieren

Stellen Sie zunächst sicher, dass Sie Ember-Assets im Produktionsmodus erstellen. Dies kann erreicht werden, indem der Server mit EMBER_ENV=production gestartet wird.

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

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

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

Wenn die Änderung dafür zu groß ist, könnten Sie Discourse in ein zweites Verzeichnis kopieren und eine zweite Kopie von ember-cli starten. Diese kann mit einem Befehl wie

EMBER_ENV=production pnpm ember serve --port 4201 --proxy http://localhost:3000

an denselben Rails-Server weitergeleitet werden.

Und dann wären Ihre beiden URLs:

http://localhost:4200
http://localhost:4201

Wenn Sie diesen Ansatz wählen, stellen Sie sicher, dass beide Kopien der Anwendung die in Schritt 1 dieser Anleitung eingeführte Leistungs­telemetrie aufweisen.

Schritt 3: Tachometer konfigurieren

Dies 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:4200",
          "name": "before"
        },
        {
          "url": "http://localhost:4201",
          "name": "after"
        }
      ]
    }
  ]
}

Schritt 4: Benchmark ausführen

Um Rauschen zu reduzieren, beenden Sie alle nicht benötigten Aktivitäten auf Ihrer Workstation und starten Sie dann den Benchmark mit einem Befehl wie:

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

Nach Abschluss sollten Sie einen Vergleich der Vorher/Nachher-Leistung sehen.

image
image1500×412 98.9 KB

Einschränkungen

Wie bei allen Experimenten dieser Art ist es sinnvoll, die Einschränkungen zu berücksichtigen. Zum Beispiel:

  • Leistungsunterschiede auf Ihrer Entwicklungs­workstation spiegeln sich möglicherweise nicht direkt auf andere Browser/Geräte wider

  • Der Bootvorgang von Discourse über den Ember-CLI-Proxy ist nicht exakt derselbe wie in der Produktion. Dies kann bei strukturellen Änderungen (z. B. Framework-Updates) wichtig sein

  • Die Leistung variiert oft je nach Anwendungszustand (z. B. der Anzahl der gerenderten Themen). Ihre Ergebnisse sind daher in anderen Umgebungen möglicherweise nicht exakt reproduzierbar.

Dieses Dokument wird versioniert – schlagen Sie Änderungen auf github vor.

17 „Gefällt mir“