Bei der Arbeit an Client-seitigen Aufgaben in Discourse-Kern, Plugins oder 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 Auswirkungen von Änderungen endgültig messen können.
Im Wesentlichen lädt dieses Tool eine Liste von URLs in einer „Round-Robin“-Methode. Für jeden Seitenaufruf werden einige Leistungsmessungen durchgeführt. Nach Hunderten oder Tausenden von Iterationen erstellt es eine Vergleichstabelle.
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 hier variiert je nachdem, was Sie testen. Im Grunde gilt: 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 eingebaute Messung „discourse-init-to-paint“ verwenden. Für alles andere können Sie Ihre eigene performance.measure-Messung einführen und diese verwenden.
Sie können prüfen, ob es funktioniert, indem Sie den Leistungs-Tab in den Entwickler-Tools Ihres Browsers verwenden:
Wenn Sie eine Aktivität messen möchten, die eine Benutzerinteraktion erfordert (z. B. das Öffnen eines Menüs), können Sie dies erreichen, indem Sie in einer Initializer-Funktion etwas wie das Folgende hinzufügen, um den Button 1 Sekunde nach dem Laden der Seite zu klicken:
setTimeout(() => document.querySelector(".my-button").click(), 1000);
Schritt 2: URLs für Tests identifizieren
Zunächst müssen Sie sicherstellen, dass Sie Ember-Assets im Produktionsmodus bauen. Dies kann erreicht werden, indem Sie den Server mit EMBER_ENV=production starten.
Um zwei verschiedene URLs zu erhalten, gibt es zwei Hauptansätze:
Wenn Ihre Änderung klein genug ist, um leicht per Feature-Flag aktiviert/deaktiviert zu werden, können Sie Logik hinzufügen, um sie basierend auf einem URL-Query-Parameter umzuschalten. Dann könnten Ihre beiden URLs lauten:
http://localhost:3000?flag=before
http://localhost:3000?flag=after
Wenn die Änderung dafür zu groß ist, können Sie Discourse in ein zweites Verzeichnis klonen und eine zweite Instanz von Rails starten.
EMBER_ENV=production UNICORN_PORT=3001 bin/dev
Und dann würden Ihre beiden URLs lauten:
http://localhost:3000
http://localhost:3001
Wenn Sie diesen Ansatz wählen, stellen Sie sicher, dass beide Kopien der App die Leistungstelemetrie enthalten, die Sie in Schritt 1 dieses Leitfadens eingeführt haben.
Schritt 3: Tachometer konfigurieren
Dies ist meine bench.json-Datei, die 300 Proben von jedem Ziel aufnehmen 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, stoppen Sie alle nicht zusammenhängenden Aktivitäten auf Ihrem Arbeitsplatz und starten Sie dann den Benchmark mit einem Befehl wie:
npx tachometer@latest --config ./bench.json
Nach Abschluss sollten Sie einen Vergleich der Leistung vor und nach der Änderung sehen.
Hinweise
Wie bei jedem solchen Experiment lohnt es sich, die Einschränkungen zu berücksichtigen. Zum Beispiel:
-
Leistungsunterschiede auf Ihrer Entwicklungs-Workstation stimmen möglicherweise nicht direkt mit denen anderer Browser/Geräte überein.
-
Der Startprozess von Discourse über den Ember-CLI-Proxy ist nicht ganz 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 Ihre Ergebnisse in anderen Umgebungen möglicherweise nicht exakt reproduzierbar.
Dieses Dokument ist versioniert – schlagen Sie Änderungen auf GitHub vor.