Ao trabalhar em código do lado do cliente no núcleo/plugins/temas do Discourse, é importante considerar o impacto no desempenho. O projeto ‘Tachometer’ do Google fornece uma ferramenta de benchmarking estatisticamente rigorosa que podemos usar para medir definitivamente o efeito das alterações.
Essencialmente, esta ferramenta pega uma lista de URLs e as carrega em um modo ‘round-robin’ (rodízio). Para cada carregamento de página, ela faz alguma medição de desempenho. Após centenas/milhares de iterações, ela produz uma tabela de comparação.
A beleza desta abordagem ‘round-robin’ é que ela ajuda a reduzir o impacto de fatores externos nas medições.
Passo 1: Adicionar performance.measure()
A abordagem aqui variará dependendo do que você está testando. Mas fundamentalmente: você precisa introduzir um valor performance.measure() para o Tachometer ler.
Se você quiser medir o tempo que leva para o Discourse inicializar e renderizar, você pode usar a medição integrada “discourse-init-to-paint”. Para qualquer outra coisa, você pode introduzir seu próprio performance.measure e usá-lo.
Você pode verificar se está funcionando usando a aba de desempenho nas ferramentas de desenvolvedor do seu navegador:
Se você estiver tentando medir uma atividade que requer interação do usuário (por exemplo, abrir um menu), você pode conseguir isso adicionando algo como isto em um inicializador para clicar no botão 1 segundo após o carregamento da página:
setTimeout(() => document.querySelector(".my-button").click(), 1000);
Passo 2: Identificar URLs para teste
Primeiramente, certifique-se de que você está construindo os assets do Ember no modo de produção. Isso pode ser alcançado iniciando o servidor com EMBER_ENV=production.
Para obter duas URLs diferentes, existem duas abordagens principais:
Se a sua alteração for pequena o suficiente para ser facilmente controlada por feature flag (bandeira de funcionalidade), então você pode adicionar lógica para alterná-la com base em um parâmetro de consulta de URL. Então, suas duas URLs poderiam ser
http://localhost:4200?flag=before
http://localhost:4200?flag=after
Se a alteração for muito grande para isso, você pode clonar o Discourse em um segundo diretório e iniciar uma segunda cópia do ember-cli. Ela pode ser redirecionada para o mesmo servidor Rails usando um comando como
EMBER_ENV=production pnpm ember serve --port 4201 --proxy http://localhost:3000
E então suas duas URLs seriam
http://localhost:4200
http://localhost:4201
Se você adotar esta abordagem, certifique-se de que ambas as cópias do aplicativo tenham a telemetria de desempenho que você introduziu na etapa 1 deste guia
Passo 3: Configurar o Tachometer
Este é o meu arquivo bench.json, que fará 300 amostras de cada alvo:
{
"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: Executar o benchmark
Para reduzir o ruído, pare quaisquer atividades não relacionadas em sua estação de trabalho e, em seguida, inicie o benchmark com um comando como:
npx tachometer@latest --config ./bench.json
Quando concluído, você deverá ver uma comparação do desempenho antes/depois.
Ressalvas
Como em qualquer experimento como este, vale a pena considerar as limitações. Por exemplo:
-
Diferenças de desempenho na sua estação de trabalho de desenvolvimento podem não corresponder diretamente a outros navegadores/dispositivos
-
O processo de inicialização do Discourse através do proxy Ember-CLI não é exatamente o mesmo que é em produção. Ao fazer alterações estruturais (por exemplo, atualizações de framework), isso pode ser importante
-
O desempenho geralmente varia com base no estado da aplicação (por exemplo, o número de tópicos sendo renderizados), então seus resultados podem não ser exatamente reproduzíveis em outros ambientes
Este documento é controlado por versão - sugira alterações no github.