Bei der Arbeit an clientseitigen Komponenten im Discourse-Kern, in Plugins oder Themes ist es wichtig, die Auswirkungen auf die Leistung zu berücksichtigen. Googles Projekt „Tachometer“ bietet ein statistisch fundiertes Benchmarking-Tool, mit dem wir die Wirkung von Änderungen eindeutig messen können.
Im Wesentlichen lädt dieses Tool eine Liste von URLs im „Round-Robin“-Verfahren. Bei jedem Seitenaufruf werden bestimmte Leistungsmessungen durchgeführt. Nach Hunderten oder Tausenden von Durchläufen wird eine Vergleichstabelle erstellt.
Der Vorteil dieses „Round-Robin“-Ansatzes besteht darin, dass er den Einfluss externer Faktoren auf die Messungen reduziert.
Schritt 1: performance.measure() hinzufügen
Der genaue Ansatz hängt davon ab, was Sie testen. Grundsätzlich müssen Sie jedoch einen performance.measure()-Wert einführen, den Tachometer auslesen kann.
Wenn Sie die Zeit messen möchten, die Discourse für den Start und das 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 nutzen.
Sie können überprüfen, ob es funktioniert, indem Sie den Reiter „Leistung“ in den Entwicklertools 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 einem Initialisierer etwas wie Folgendes 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
Stellen Sie zunächst sicher, dass Sie Ember-Assets im Produktionsmodus erstellen. 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 einfach über einen Feature-Flag gesteuert zu werden, können Sie eine Logik hinzufügen, um sie basierend auf einem URL-Abfrageparameter umzuschalten. Dann könnten Ihre beiden URLs sein:
http://localhost:3000?flag=before
http://localhost:3000?flag=after
Wenn die Änderung zu groß dafür 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
Dann wären Ihre beiden URLs:
http://localhost:3000
http://localhost:3001
Wenn Sie diesen Ansatz wählen, stellen Sie sicher, dass beide Instanzen der Anwendung die in Schritt 1 dieses Leitfadens eingeführten Leistungstelemetriedaten enthalten.
Schritt 3: Tachometer konfigurieren
Dies ist meine bench.json-Datei, die 300 Stichproben für jedes Ziel nimmt:
{
"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 Störungen zu minimieren, beenden Sie alle nicht relevanten 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 Leistung vor/nach der Änderung sehen.
Einschränkungen
Wie bei jedem solchen Experiment lohnt es sich, die Grenzen zu bedenken. Zum Beispiel:
-
Leistungsunterschiede auf Ihrer Entwicklungsmaschine lassen sich möglicherweise nicht direkt auf andere Browser oder Geräte übertragen.
-
Der Boot-Prozess von Discourse über den Ember-CLI-Proxy ist nicht exakt derselbe wie in der Produktion. Bei strukturellen Änderungen (z. B. Framework-Updates) kann dies wichtig sein.
-
Die Leistung variiert oft je nach Anwendungsstatus (z. B. Anzahl der gerenderten Themen), sodass Ihre Ergebnisse in anderen Umgebungen möglicherweise nicht exakt reproduzierbar sind.
Dieses Dokument ist versionskontrolliert – Änderungen können auf GitHub vorgeschlagen werden.