Ao trabalhar em tarefas do lado do cliente no núcleo, plugins ou temas do Discourse, é importante considerar o impacto no desempenho. O projeto ‘Tachometer’ da Google fornece uma ferramenta de benchmarking estatisticamente rigorosa que podemos usar para medir definitivamente o efeito das alterações.
Basicamente, essa ferramenta recebe uma lista de URLs e as carrega de forma ‘round-robin’ (alternada). Para cada carregamento de página, ela realiza uma medição de desempenho. Após centenas ou 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 de performance.measure() para o Tachometer ler.
Se você quiser medir o tempo que o Discourse leva para iniciar 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 desenvolvimento do seu navegador:
Se você estiver tentando medir uma atividade que requer interação do usuário (por exemplo, abrir um menu), você pode alcançar isso adicionando algo como o seguinte em um inicializador para clicar no botão 1 segundo após a página ser carregada:
setTimeout(() => document.querySelector(".my-button").click(), 1000);
Etapa 2: Identificar URLs para teste
Primeiro, certifique-se de que você está compilando os assets do Ember em modo de produção. Isso pode ser feito iniciando o servidor com EMBER_ENV=production.
Para obter duas URLs diferentes, existem duas abordagens principais:
Se sua alteração for pequena o suficiente para ser facilmente controlada por uma bandeira de recurso (feature flag), você pode adicionar lógica para alterná-la com base em um parâmetro de consulta da URL. Então, suas duas URLs seriam:
http://localhost:3000?flag=antes
http://localhost:3000?flag=depois
Se a alteração for grande demais para isso, você pode clonar o Discourse em um segundo diretório e iniciar uma segunda cópia do rails.
EMBER_ENV=production UNICORN_PORT=3001 bin/dev
E então suas duas URLs seriam:
http://localhost:3000
http://localhost:3001
Se você seguir essa 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 é meu arquivo bench.json, que coletará 300 amostras de cada alvo:
{
"timeout": 5,
"sampleSize": 300,
"benchmarks": [
{
"measurement": {
"mode": "performance",
"entryName": "discourse-init-to-paint"
},
"expand": [
{
"url": "http://localhost:3000",
"name": "antes"
},
{
"url": "http://localhost:3001",
"name": "depois"
}
]
}
]
}
Etapa 4: Executar o benchmark
Para reduzir o ruído, pare qualquer atividade não relacionada na sua estação de trabalho e, em seguida, inicie o benchmark com um comando como:
npx tachometer@latest --config ./bench.json
Ao concluir, você deve ver uma comparação do desempenho antes/depois.
Ressalvas
Como em qualquer experimento desse tipo, vale a pena considerar as limitações. Por exemplo:
-
Diferenças de desempenho na sua estação de desenvolvimento podem não se traduzir diretamente para outros navegadores/dispositivos
-
O processo de inicialização do Discourse através do proxy do 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 frequentemente 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.