Usare il 'tachometer' di Google per misurare le variazioni delle prestazioni JS in Discourse

Documentazione Guide per sviluppatori
1

Quando si lavora su funzionalità 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.

In sostanza, questo strumento accetta un elenco di URL e li carica in modalità ‘round-robin’. Per ogni caricamento della pagina, acquisisce alcune metriche di prestazione. 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 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 la propria performance.measure e utilizzarla.

È possibile verificare che funzioni utilizzando la scheda Prestazioni negli strumenti per sviluppatori del browser:

SCR-20240529-rlhj
SCR-20240529-rlhj1234×176 5.86 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 initializer 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

n
Prima di tutto, assicurarsi di compilare 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/disabilitata tramite feature flag, è possibile aggiungere logica per commutarla in base a un parametro di query dell’URL. Quindi i due URL potrebbero essere:

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

Se la modifica è troppo grande per questo, è possibile creare un git worktree e avviare una seconda copia di rails da esso su un’altra porta:

git worktree add ../discourse-after my-branch
cd ../discourse-after
bundle install
pnpm install
EMBER_ENV=production UNICORN_PORT=3001 bin/dev

Entrambe le copie condividono lo stesso database e Redis, quindi assicurarsi che nessun ramo abbia migrazioni che l’altro non ha.

E quindi i due URL sarebbero:

http://localhost:3000
http://localhost:3001

Se si adotta questo approccio, assicurarsi che entrambe le copie dell’app abbiano la 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 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, interrompere tutte le attività non correlate sulla workstation e quindi avviare il benchmark con un comando come:

pnpx tachometer --config ./bench.json

Al completamento, dovresti vedere un confronto delle prestazioni prima/dopo.

image
image1500×412 48.9 KB

Avvertenze

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

  • Le differenze di prestazioni sulla workstation di sviluppo potrebbero non corrispondere direttamente ad altri browser/dispositivi

  • Il processo di avvio di Discourse in modalità di sviluppo non è esattamente lo stesso di quello in produzione. Quando si apportano modifiche strutturali (ad esempio, aggiornamenti del framework), questo potrebbe essere importante

  • Le prestazioni variano spesso 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.

17 Mi Piace