Al trabajar en el lado del cliente en el núcleo de Discourse, plugins o temas, es importante considerar el impacto en el rendimiento. El proyecto ‘Tachometer’ de Google proporciona una herramienta de referencia estadísticamente rigurosa que podemos utilizar para medir definitivamente el efecto de los cambios.
Básicamente, esta herramienta toma una lista de URLs y las carga de forma ‘round-robin’. Para cada carga de página, realiza una medición de rendimiento. Después de cientos/miles de iteraciones, genera 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: Agregar performance.measure()
El enfoque variará según lo que estés probando. Pero fundamentalmente: necesitas introducir un valor performance.measure() que Tachometer pueda leer.
Si deseas medir el tiempo que tarda Discourse en iniciarse y renderizarse, puedes utilizar la medición integrada “discourse-init-to-paint”. Para cualquier otra cosa, puedes introducir tu propia performance.measure y utilizarla.
Puedes verificar que funcione utilizando la pestaña de rendimiento en las herramientas de desarrollo de tu navegador:
Si intentas 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 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 compilando los recursos de Ember en modo 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 para ser fácilmente controlado por una bandera de características, podrías añadir lógica para alternarlo basándote en un parámetro de consulta de la 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, 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 la referencia
Para reducir el ruido, detén cualquier actividad no relacionada en tu estación de trabajo y luego inicia la referencia con un comando como:
npx tachometer@latest --config ./bench.json
Al finalizar, 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 corresponderse directamente con 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 del 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 tiene control de versiones: sugiere cambios en GitHub.