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, essa ferramenta pega uma lista de URLs e as carrega de forma ‘round-robin’. Para cada carregamento de página, ela faz uma medição de desempenho. Após centenas/milhares de iterações, ela produz uma tabela de comparação.
A beleza dessa abordagem ‘round-robin’ é que ela ajuda a reduzir o impacto de fatores externos nas medições.
Etapa 1: Adicionar performance.measure()
A abordagem aqui variará com base no que você está testando. Mas fundamentalmente: você precisa introduzir um valor performance.measure() para o Tachometer ler.
Se você quiser renderizar o tempo que o Discourse leva para inicializar e renderizar, 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);
Etapa 2: Identificar URLs para teste
Primeiro, 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 dois URLs diferentes, existem duas abordagens principais:
Se sua alteração for pequena o suficiente para ser facilmente controlada por feature flag, você pode adicionar lógica para alterná-la com base em um parâmetro de consulta de URL. Então seus dois 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 encaminhada para o mesmo servidor Rails usando um comando como
EMBER_ENV=production pnpm ember serve --port 4201 --proxy http://localhost:3000
E então seus dois URLs seriam
http://localhost:4200
http://localhost:4201
Se você seguir 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.
Etapa 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"
}
]
}
]
}
Etapa 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 em sua estação de trabalho de desenvolvimento podem não se traduzir diretamente em 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), portanto, seus resultados podem não ser exatamente reproduzíveis em outros ambientes.
Este documento é versionado - sugira alterações no github.