Al trabajar en el lado del cliente en el núcleo, plugins o temas de Discourse, es importante considerar el impacto en el rendimiento. El proyecto ‘Tachometer’ de Google proporciona una herramienta de benchmarking estadísticamente rigurosa que podemos utilizar para medir de manera definitiva el efecto de los cambios.
En esencia, esta herramienta toma una lista de URLs y las carga de manera ‘round-robin’. Para cada carga de página, toma algunas mediciones de rendimiento. Después de cientos o miles de iteraciones, produce una tabla de comparación.
La belleza de este enfoque ‘round-robin’ es que ayuda a reducir el impacto de los factores externos en las mediciones.
Paso 1: Agregar 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 iniciar y renderizar, puedes usar la medición integrada “discourse-init-to-paint”. Para cualquier otra cosa, puedes introducir tu propio performance.measure y usarlo.
Puedes verificar que funciona usando la pestaña de rendimiento en las herramientas de desarrollo de tu navegador:
Si estás intentando medir una actividad que requiere interacción del usuario (por ejemplo, abrir un menú), podrías lograrlo agregando algo como esto en un inicializador para hacer clic en el botón 1 segundo después de que se cargue la página:
setTimeout(() => document.querySelector(".my-button").click(), 1000);
Paso 2: Identificar URLs para pruebas
En primer lugar, asegúrate de que estás construyendo los activos de Ember en modo de 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 habilitado mediante una bandera de función (feature flag), entonces podrías agregar lógica para alternarlo basado en un parámetro de consulta de URL. Entonces, tus dos URLs podrían ser:
http://localhost:3000?flag=before
http://localhost:3000?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 rails.
EMBER_ENV=production UNICORN_PORT=3001 bin/dev
Y entonces tus dos URLs serían:
http://localhost:3000
http://localhost:3001
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:3000",
"name": "before"
},
{
"url": "http://localhost:3001",
"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
Al completarse, 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 corresponder directamente a 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 marco de trabajo), 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á bajo control de versiones - sugiere cambios en github.