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

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 di 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.

Passo 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 a Discourse per avviarsi e renderizzare, è 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:

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

Innanzitutto, assicurarsi di compilare 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 è abbastanza piccola da poter essere facilmente gestita tramite flag di funzionalità, è possibile aggiungere una logica per attivarla/disattivarla in base a un parametro di query dell’URL. Quindi i 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 inoltrata allo stesso server Rails utilizzando un comando come

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

E quindi i due URL sarebbero

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

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

Passo 3: Configurare Tachometer

Questo è il mio file bench.json, che acquisirà 300 campioni di ciascun obiettivo:

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

Passo 4: Eseguire il benchmark

Per ridurre il rumore, interrompere qualsiasi attività non correlata sulla workstation 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.

Avvertenze

Come per tutti gli esperimenti 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 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 sottoposti a rendering), quindi i risultati potrebbero non essere riproducibili esattamente in altri ambienti


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

17 Mi Piace