Ao trabalhar com código no lado do cliente no núcleo, plugins ou temas do Discourse, é importante considerar o impacto no desempenho. O projeto ‘Tachometer’ do Google fornece uma ferramenta de benchmark estatisticamente rigorosa que podemos usar para medir definitivamente o efeito das alterações.
Essencialmente, essa ferramenta recebe uma lista de URLs e as carrega de forma ‘round-robin’ (cíclica). Para cada carregamento de página, ela realiza uma medição de desempenho. Após centenas ou milhares de iterações, ela gera uma tabela de comparação.
A vantagem dessa 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 que o Tachometer possa ler.
Se você quiser medir 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 criar seu próprio performance.measure e utilizá-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), pode fazer isso adicionando algo como o código abaixo 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
Primeiro, certifique-se de que está compilando os ativos do Ember no 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 um recurso (feature flag), você pode adicionar lógica para alterná-la com base em um parâmetro de consulta da URL. Assim, suas duas URLs poderiam ser:
http://localhost:3000?flag=before
http://localhost:3000?flag=after
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 seguir essa abordagem, certifique-se de que ambas as cópias do aplicativo tenham a telemetria de desempenho introduzida no passo 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:3000",
"name": "before"
},
{
"url": "http://localhost:3001",
"name": "after"
}
]
}
]
}
Passo 4: Executar o benchmark
Para reduzir ruídos, 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ê deverá ver uma comparação do desempenho antes/depois.
Observações
Como em qualquer experimento desse tipo, 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 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 do aplicativo (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 está sob controle de versão — sugira alterações no GitHub.