Lorsque vous travaillez sur le code côté client dans le cœur de Discourse, ses plugins ou ses thèmes, il est important de prendre en compte l’impact sur les performances. Le projet « Tachometer » de Google fournit un outil de benchmarking rigoureux sur le plan statistique, que nous pouvons utiliser pour mesurer de manière définitive l’effet des modifications.
Essentiellement, cet outil prend une liste d’URL et les charge de manière « round-robin » (tour à tour). Pour chaque chargement de page, il effectue une mesure de performance. Après des centaines ou des milliers d’itérations, il génère un tableau comparatif.
L’avantage de cette approche « round-robin » est qu’elle aide à réduire l’impact des facteurs externes sur les mesures.
Étape 1 : Ajouter performance.measure()
L’approche varie selon ce que vous testez. Mais fondamentalement : vous devez introduire une valeur performance.measure() que Tachometer pourra lire.
Si vous souhaitez mesurer le temps nécessaire au démarrage et au rendu de Discourse, vous pouvez utiliser la mesure intégrée « discourse-init-to-paint ». Pour tout autre cas, vous pouvez introduire votre propre performance.measure et l’utiliser.
Vous pouvez vérifier que cela fonctionne en utilisant l’onglet « Performance » des outils de développement de votre navigateur :
Si vous essayez de mesurer une activité nécessitant une interaction utilisateur (par exemple, ouvrir un menu), vous pouvez y parvenir en ajoutant quelque chose comme ceci dans un initialiseur pour cliquer sur le bouton 1 seconde après le chargement de la page :
setTimeout(() => document.querySelector(".my-button").click(), 1000);
Étape 2 : Identifier les URL à tester
Tout d’abord, assurez-vous de compiler les assets Ember en mode production. Cela peut être réalisé en lançant le serveur avec EMBER_ENV=production.
Pour obtenir deux URL différentes, il existe deux approches principales :
Si votre modification est suffisamment petite pour être facilement gérée par un drapeau de fonctionnalité, vous pouvez ajouter une logique pour l’activer ou la désactiver en fonction d’un paramètre de requête URL. Vos deux URL pourraient alors être :
http://localhost:3000?flag=before
http://localhost:3000?flag=after
Si la modification est trop importante pour cela, vous pouvez cloner Discourse dans un deuxième répertoire et lancer une deuxième copie de rails.
EMBER_ENV=production UNICORN_PORT=3001 bin/dev
Vos deux URL seraient alors :
http://localhost:3000
http://localhost:3001
Si vous choisissez cette approche, assurez-vous que les deux copies de l’application disposent de la télémétrie de performance introduite à l’étape 1 de ce guide.
Étape 3 : Configurer Tachometer
Voici mon fichier bench.json, qui prendra 300 échantillons de chaque cible :
{
"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"
}
]
}
]
}
Étape 4 : Lancer le benchmark
Pour réduire le bruit, arrêtez toute activité non liée sur votre station de travail, puis lancez le benchmark avec une commande comme :
npx tachometer@latest --config ./bench.json
Une fois terminé, vous devriez voir une comparaison des performances avant/après.
Précautions
Comme pour toute expérience de ce type, il convient de prendre en compte les limites. Par exemple :
-
Les différences de performance sur votre station de travail de développement peuvent ne pas se traduire directement sur d’autres navigateurs ou appareils.
-
Le processus de démarrage de Discourse via le proxy Ember-CLI n’est pas exactement le même qu’en production. Lors de modifications structurelles (par exemple, des mises à jour du framework), cela peut être important.
-
Les performances varient souvent en fonction de l’état de l’application (par exemple, le nombre de sujets rendus), il est donc possible que vos résultats ne soient pas exactement reproductibles dans d’autres environnements.
Ce document est versionné – proposez des modifications sur GitHub.