Quando si lavora su codice lato client nel core di Discourse, nei plugin o nei temi, è importante considerare l’impatto sulle prestazioni. Il progetto ‘Tachometer’ di Google offre uno strumento di benchmarking statisticamente rigoroso che possiamo utilizzare per misurare in modo definitivo l’effetto delle modifiche.
Essenzialmente, questo strumento prende un elenco di URL e li carica in modo «round-robin». Per ogni caricamento della pagina, esegue alcune misurazioni delle prestazioni. Dopo centinaia/migliaia di iterazioni, genera una tabella di confronto.
La bellezza di questo approccio «round-robin» è che aiuta a ridurre l’impatto di fattori esterni sulle misurazioni.
Passo 1: Aggiungere performance.measure()
L’approccio varierà in base a ciò che si sta testando. Ma fondamentalmente: è necessario introdurre un valore performance.measure() che Tachometer possa leggere.
Se si vuole misurare il tempo necessario a Discourse per avviarsi e rendersi, è possibile utilizzare la misurazione integrata “discourse-init-to-paint”. Per qualsiasi altra cosa, è possibile introdurre il proprio performance.measure e utilizzarlo.
È possibile verificare che funzioni utilizzando la scheda «Prestazioni» negli strumenti per sviluppatori del browser:
Se si sta cercando di misurare un’attività che richiede interazione dell’utente (ad esempio, aprire un menu), si può ottenere questo aggiungendo qualcosa del genere 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 i test
Per prima cosa, assicurarsi di costruire le risorse Ember in modalità 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 essere facilmente gestita tramite feature flag, è possibile aggiungere una logica per attivarla/disattivarla in base a un parametro di query URL. In tal caso, i due URL potrebbero essere:
http://localhost:3000?flag=before
http://localhost:3000?flag=after
Se la modifica è troppo grande per questo approccio, è possibile clonare Discourse in una seconda directory e avviare una seconda copia di rails.
EMBER_ENV=production UNICORN_PORT=3001 bin/dev
E in tal caso i due URL sarebbero:
http://localhost:3000
http://localhost:3001
Se si adotta questo approccio, assicurarsi che entrambe le copie dell’applicazione includano la telemetria delle prestazioni introdotta nel passo 1 di questa guida.
Passo 3: Configurare Tachometer
Questo è il mio file bench.json, che effettuerà 300 campioni per ciascun 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, fermare qualsiasi attività non correlata sulla workstation e quindi avviare il benchmark con un comando simile a:
npx tachometer@latest --config ./bench.json
Al termine, dovrebbe essere visualizzato un confronto delle prestazioni prima/dopo.
Avvertenze
Come con qualsiasi esperimento di questo tipo, vale la pena considerare le limitazioni. Ad esempio:
-
Le differenze di prestazioni sulla workstation 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 che in produzione. Quando si apportano modifiche strutturali (ad esempio, aggiornamenti del framework) ciò potrebbe essere importante
-
Le prestazioni spesso variano in base allo stato dell’applicazione (ad esempio, il numero di argomenti in rendering), quindi i risultati potrebbero non essere esattamente riproducibili in altri ambienti
Questo documento è sottoposto a controllo delle versioni: suggerire modifiche su GitHub.