Quando si lavora su componenti lato client in Discourse (core, plugin o temi), è importante considerare l’impatto sulle prestazioni. Il progetto ‘Tachometer’ di Google fornisce uno strumento di benchmarking statisticamente rigoroso che possiamo utilizzare per misurare in modo definitivo l’effetto delle modifiche.
In sostanza, questo strumento accetta un elenco di URL e li carica in modo ‘round-robin’. Per ogni caricamento della pagina, esegue alcune misurazioni delle prestazioni. Dopo centinaia o migliaia di iterazioni, produce una tabella di confronto.
La bellezza di questo approccio ‘round-robin’ è che aiuta a ridurre l’impatto dei fattori esterni sulle misurazioni.
Passo 1: Aggiungere performance.measure()
L’approccio varierà in base a ciò che si sta testando. Ma in linea di principio: è necessario introdurre un valore di performance.measure() che Tachometer possa leggere.
Se si desidera misurare il tempo necessario a Discourse per l’avvio e il rendering, è possibile utilizzare la misurazione integrata “discourse-init-to-paint”. Per qualsiasi altra cosa, è possibile introdurre la propria performance.measure e utilizzarla.
Puoi verificare che funzioni utilizzando la scheda prestazioni negli strumenti di sviluppo del browser:
Se si sta cercando di misurare un’attività che richiede l’interazione dell’utente (ad esempio, l’apertura di un menu), è possibile ottenerlo aggiungendo qualcosa di simile in un inizializzatore per fare clic sul pulsante 1 secondo dopo il caricamento della pagina:
setTimeout(() => document.querySelector(".my-button").click(), 1000);
Passo 2: Identificare gli URL per il test
nanzitutto, assicurati di costruire gli asset Ember in modalità di produzione. Questo può essere ottenuto avviando il server con EMBER_ENV=production.
Per ottenere due URL diversi, ci sono due approcci principali:
Se la modifica è abbastanza piccola da poter essere facilmente abilitata tramite flag, è possibile aggiungere la logica per attivarla in base a un parametro di query dell’URL. Quindi i tuoi due URL potrebbero essere
http://localhost:3000?flag=before
http://localhost:3000?flag=after
Se la modifica è troppo grande per questo, è possibile clonare Discourse in una seconda directory e avviare una seconda copia di rails.
EMBER_ENV=production UNICORN_PORT=3001 bin/dev
E poi i tuoi due URL sarebbero
http://localhost:3000
http://localhost:3001
Se si adotta questo approccio, assicurarsi che entrambe le copie dell’app dispongano della telemetria delle prestazioni introdotta nel passo 1 di questa guida
Passo 3: Configurare Tachometer
Questo è il mio file bench.json, che preleverà 300 campioni di ogni target:
{
"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"
}
]
}
]
}
Passo 4: Eseguire il benchmark
Per ridurre il rumore, interrompere tutte le attività non correlate sulla propria postazione di lavoro e quindi avviare il benchmark con un comando come:
npx tachometer@latest --config ./bench.json
Al termine, dovresti vedere un confronto delle prestazioni prima/dopo.
Avvertenze
Come per qualsiasi esperimento di questo tipo, vale la pena considerare i limiti. Ad esempio:
-
Le differenze di prestazioni sulla postazione di sviluppo potrebbero non corrispondere direttamente ad altri browser/dispositivi
-
Il processo di avvio di Discourse tramite il proxy Ember-CLI non è esattamente lo stesso di quello in produzione. Quando si apportano modifiche strutturali (ad esempio aggiornamenti del framework), questo potrebbe essere importante
-
Le prestazioni spesso variano in base allo stato dell’applicazione (ad esempio, il numero di topic renderizzati), quindi i risultati potrebbero non essere esattamente riproducibili in altri ambienti
Questo documento è versionato - suggerisci modifiche su github.