Utilizzo del 'tachometer' di Google per misurare i cambiamenti delle prestazioni JS in Discourse

Documentazione Guide per sviluppatori
1

Quando si lavora su codice lato client in Discourse core/plugin/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.

Essenzialmente, questo strumento prende un elenco di URL e li carica in modo ‘round-robin’. Per ogni caricamento della pagina, esegue una misurazione delle prestazioni. Dopo centinaia/migliaia di iterazioni, produce una tabella di confronto.

La bellezza di questo approccio ‘round-robin’ è che aiuta a ridurre l’impatto di fattori esterni sulle misurazioni.

Passaggio 1: Aggiungere performance.measure()

L’approccio qui varierà in base a ciò che si sta testando. Ma fondamentalmente: è necessario introdurre un valore performance.measure() che Tachometer possa leggere.

Se si desidera misurare il tempo necessario per l’avvio e il rendering di Discourse, è 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 delle prestazioni negli strumenti per sviluppatori del browser:

SCR-20240529-rlhj
SCR-20240529-rlhj1234×176 9.92 KB

Se si sta cercando di misurare un’attività che richiede l’interazione dell’utente (ad esempio, l’apertura di un menu), è possibile ottenere questo risultato 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);

Passaggio 2: Identificare gli URL per il test

Innanzitutto, assicurarsi che si stiano compilando gli asset Ember in modalità di produzione. Ciò può essere ottenuto avviando il server con EMBER_ENV=production.

Per ottenere due URL diversi, ci sono due approcci principali:

Se la modifica è sufficientemente piccola da poter essere facilmente gestita tramite feature flag, è possibile aggiungere una logica per attivarla in base a un parametro di query dell’URL. Quindi i tuoi due URL potrebbero essere:

http://localhost:4200?flag=before
http://localhost:4200?flag=after

Se la modifica è troppo grande per questo, è possibile clonare Discourse in una seconda directory e avviare una seconda copia di ember-cli. Può essere proxato allo stesso server Rails utilizzando un comando come:

EMBER_ENV=production pnpm ember serve --port 4201 --proxy http://localhost:3000

E quindi i tuoi due URL sarebbero:

http://localhost:4200
http://localhost:4201

Se si adotta questo approccio, assicurarsi che entrambe le copie dell’app abbiano la telemetria delle prestazioni introdotta nel passaggio 1 di questa guida.

Passaggio 3: Configurare Tachometer

Questo è il mio file bench.json, che prenderà 300 campioni per ciascun target:

{
  "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"
        }
      ]
    }
  ]
}

Passaggio 4: Eseguire il benchmark

Per ridurre il rumore, interrompere qualsiasi attività non correlata sulla propria postazione di lavoro e quindi avviare il benchmark con un comando come:

npx tachometer@latest --config ./bench.json

Al termine, si dovrebbe vedere un confronto delle prestazioni prima/dopo.

image
image1500×412 98.9 KB

Avvertenze

Come per qualsiasi esperimento di questo tipo, vale la pena considerare i limiti. Ad esempio:

  • Le differenze di prestazioni sulla propria 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), ciò potrebbe essere importante.

  • Le prestazioni variano spesso in base allo stato dell’applicazione (ad esempio, il numero di argomenti visualizzati), quindi i risultati potrebbero non essere esattamente riproducibili in altri ambienti.

Questo documento è controllato in versione - suggerisci modifiche su github.

17 Mi Piace