Al trabajar en el 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 utilizar para medir de forma definitiva el efecto de los cambios.
Esencialmente, esta herramienta toma una lista de URLs y las carga de forma ‘aleatoria’. Para cada carga de página, toma alguna medida de rendimiento. Después de cientos/miles de iteraciones, produce una tabla de comparación.
La belleza de este enfoque ‘aleatorio’ 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 performance.measure() para que Tachometer lo lea.
Si quieres medir el tiempo que tarda Discourse en arrancar 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 comprobar que funciona utilizando 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 cargue:
setTimeout(() => document.querySelector(".my-button").click(), 1000);
Paso 2: Identificar URLs para probar
En primer lugar, asegúrate de que estás compilando 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, existen dos enfoques principales:
Si tu cambio es lo suficientemente pequeño como para ser fácilmente activado/desactivado por una 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. Puede ser redirigido al mismo servidor Rails utilizando 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 eliges 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 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 termine, 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 Ember-CLI no es exactamente el mismo que en producción. Al realizar cambios estructurales (por ejemplo, actualizaciones de framework), 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á versionado - sugiere cambios en github.