Al trabajar en código del lado del cliente en Discourse core/plugins/themes, es importante considerar el impacto en el rendimiento. El proyecto ‘Tachometer’ de Google proporciona una herramienta de benchmarking estadísticamente rigurosa que podemos usar para medir de forma definitiva el efecto de los cambios.
Esencialmente, esta herramienta toma una lista de URLs y las carga en un modo ‘round-robin’ (secuencial rotatorio). Para cada carga de página, toma alguna medida de rendimiento. Después de cientos/miles de iteraciones, produce una tabla comparativa.
La belleza de este enfoque ‘round-robin’ es que ayuda a reducir el impacto de factores externos en las mediciones.
Paso 1: Añadir performance.measure()
El enfoque aquí variará según lo que estés probando. Pero fundamentalmente: necesitas introducir un valor de performance.measure() para que Tachometer lo lea.
Si quieres medir el tiempo que tarda Discourse en arrancar y renderizar, puedes usar la medición incorporada “discourse-init-to-paint”. Para cualquier otra cosa, puedes introducir tu propio performance.measure y usarlo.
Puedes comprobar que funciona usando la pestaña de rendimiento en las herramientas de desarrollador de tu navegador:
Si estás intentando medir una actividad que requiere interacción del usuario (por ejemplo, abrir un menú), podrías lograrlo añadiendo algo como esto en un inicializador para hacer clic en el botón 1 segundo después de que la página se haya cargado:
setTimeout(() => document.querySelector(".my-button").click(), 1000);
Paso 2: Identificar URLs para las pruebas
En primer lugar, asegúrate de que estás compilando los assets de Ember en modo producción. Esto se puede lograr iniciando el servidor con EMBER_ENV=production.
Para obtener dos URLs diferentes, hay dos enfoques principales:
Si tu cambio es lo suficientemente pequeño como para ser fácilmente controlado por una feature flag (bandera de funcionalidad), entonces podrías añadir lógica para activarlo/desactivarlo basándote en un parámetro de consulta de URL. Entonces tus dos URLs podrían ser
http://localhost:4200?flag=before
http://localhost:4200?flag=after
Si el cambio es demasiado grande para eso, entonces podrías clonar Discourse en un segundo directorio e iniciar una segunda copia de ember-cli. Se puede reenviar (proxy) al mismo servidor Rails usando un comando como
EMBER_ENV=production pnpm ember serve --port 4201 --proxy http://localhost:3000
Y entonces tus dos URLs serían
http://localhost:4200
http://localhost:4201
Si tomas este enfoque, asegúrate de que ambas copias de la aplicación tengan la telemetría de rendimiento que introdujiste en el paso 1 de esta guía.
Paso 3: Configurar Tachometer
Este es mi archivo bench.json, que tomará 300 muestras de cada objetivo:
{
"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"
}
]
}
]
}
Paso 4: Ejecutar el benchmark
Para reducir el ruido, detén cualquier actividad no relacionada en tu estación de trabajo y luego inicia el benchmark con un comando como:
npx tachometer@latest --config ./bench.json
Cuando finalice, deberías ver una comparación del rendimiento antes/después.
Advertencias
Como con cualquier experimento de este tipo, vale la pena considerar las limitaciones. Por ejemplo:
-
Las diferencias de rendimiento en tu estación de trabajo de desarrollo pueden no reflejarse directamente en otros navegadores/dispositivos
-
El proceso de arranque de Discourse a través del proxy de Ember-CLI no es exactamente el mismo que en producción. Al realizar cambios estructurales (por ejemplo, actualizaciones de frameworks) esto puede ser importante
-
El rendimiento a menudo varía según el estado de la aplicación (por ejemplo, el número de temas que se están renderizando), por lo que tus resultados pueden no ser exactamente reproducibles en otros entornos
Este documento está controlado por versiones: sugiere cambios en github.