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 forma definitiva el efecto de los cambios.
Básicamente, esta herramienta toma una lista de URLs y las carga de manera ‘round-robin’ (rotativa). Para cada carga de página, toma algunas medidas de rendimiento. Después de cientos o miles de iteraciones, genera 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 pueda leerlo.
Si deseas 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 las pruebas
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, hay dos enfoques principales:
Si tu cambio es lo suficientemente pequeño como para poder activarse fácilmente con una bandera de función (feature flag), puedes agregar lógica para alternarlo basándote 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, puedes crear un árbol de trabajo de git (git worktree) e iniciar una segunda copia de rails desde él en otro puerto:
git worktree add ../discourse-after my-branch
cd ../discourse-after
bundle install
pnpm install
EMBER_ENV=production UNICORN_PORT=3001 bin/dev
Ambas copias comparten la misma base de datos y Redis, así que asegúrate de que ninguna rama tenga migraciones que la otra no tenga.
Y entonces, tus dos URLs serían:
http://localhost:3000
http://localhost:3001
Si sigues 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:
pnpx tachometer --config ./bench.json
Al completar, deberías ver una comparación del rendimiento antes/después.
Precauciones
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 con otros navegadores/dispositivos.
-
El proceso de arranque de Discourse en modo de desarrollo 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á bajo control de versiones - sugiere cambios en github.