Bei der Arbeit an clientseitiger Funktionalität in Discourse Core/Plugins/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 Auswirkungen von Änderungen eindeutig messen können.
Im Wesentlichen nimmt dieses Tool eine Liste von URLs und lädt sie ‘im Round-Robin-Verfahren’. Für jeden Seitenaufruf nimmt es eine Leistungsmessung vor. Nach Hunderten/Tausenden von Iterationen erstellt es eine Vergleichstabelle.
Der Vorteil dieses ‘Round-Robin’-Ansatzes besteht darin, dass er dazu beiträgt, die Auswirkungen 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 Booten und Rendern benötigt, können Sie die integrierte Messung “discourse-init-to-paint” verwenden. Für alles andere können Sie Ihr eigenes performance.measure einführen und dieses verwenden.
Sie können überprüfen, ob es funktioniert, indem Sie den Leistungsreiter in den Entwicklertools Ihres Browsers verwenden:
Wenn Sie eine Aktivität messen möchten, die Benutzerinteraktion erfordert (z. B. das Öffnen eines Menüs), könnten Sie dies erreichen, indem Sie in einem Initialisierer etwas wie das Folgende hinzufügen, um eine Sekunde nach dem Laden der Seite auf die Schaltfläche 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 durch Starten des Servers mit EMBER_ENV=production erreicht werden.
Um zwei verschiedene URLs zu erhalten, gibt es zwei Hauptansätze:
Wenn Ihre Änderung klein genug ist, um leicht 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 klonen und eine zweite Instanz von ember-cli starten. Diese kann mit einem Befehl wie dem folgenden auf denselben Rails-Server weitergeleitet werden:
EMBER_ENV=production pnpm ember serve --port 4201 --proxy http://localhost:3000
Und dann wären Ihre beiden URLs:
http://localhost:4200
http://localhost:4201
Wenn Sie diesen Ansatz wählen, stellen Sie sicher, dass beide Instanzen der Anwendung die in Schritt 1 dieser Anleitung eingeführte Leistungstelemetrie haben.
Schritt 3: Tachometer konfigurieren
Dies ist meine bench.json-Datei, die 300 Stichproben von jedem Ziel nimmt:
{
"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 verwandten 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 und nach der Änderung sehen.
Vorbehalte
Wie bei allen Experimenten dieser Art ist es sinnvoll, die Einschränkungen zu berücksichtigen. Zum Beispiel:
-
Leistungsunterschiede auf Ihrer Entwickler-Workstation spiegeln sich möglicherweise nicht direkt auf andere Browser/Geräte wider.
-
Der Bootvorgang von Discourse über den Ember-CLI-Proxy ist nicht genau derselbe wie in der Produktion. Bei strukturellen Änderungen (z. B. Framework-Updates) kann dies wichtig sein.
-
Die Leistung variiert häufig je nach Anwendungszustand (z. B. der Anzahl der gerenderten Themen), sodass Ihre Ergebnisse in anderen Umgebungen möglicherweise nicht exakt reproduzierbar sind.
Dieses Dokument wird versioniert – schlagen Sie Änderungen auf GitHub vor.