Tenho analisado o desempenho do plugin ActivityPub recentemente e considerado as melhores formas de testar e comprovar de forma confiável o desempenho para o propósito de tal projeto. Aqui estão algumas informações iniciais:
- O plugin é um projeto de código aberto com várias partes envolvidas (ou seja, Discourse, que é o proprietário do plugin, e Pavilion, que o está desenvolvendo atualmente).
- Partes diferentes podem ter ferramentas/sistemas internos de teste de desempenho diferentes.
- Projetos de código aberto multipartidários beneficiam-se de métodos comumente disponíveis para testar e comprovar que algo funciona, ou neste caso, tem um desempenho confiável.
- O Discourse (louvavelmente) se preocupa com o desempenho.
No Discourse, acreditamos que o desempenho é um recurso. Damos as boas-vindas a pull requests que melhoram o desempenho do lado do cliente ou do servidor.
- Atualmente, o único método comumente disponível para testar/comprovar o desempenho do lado do servidor no Discourse (que eu conheça) é o
track_sql_queries(discourse/spec/support/helpers.rb at 467e1a1bddb8266e4ab1165fbba71745d4f9c269 · discourse/discourse · GitHub), que é tipicamente (mas não exclusivamente) usado em testes de requisição. - Embora a contagem de consultas seja um indicador de desempenho, não é o único (algumas consultas são maiores que outras).
Para um exemplo recente do uso de track_sql_queries, veja
Se você está familiarizado com esta área, provavelmente sabe algo como
A regra geral é que testes unitários precisam de velocidade e testes de desempenho precisam de tempo.
(citação de este explicador decente)
O que, à primeira vista, pode tornar o teste de desempenho (além da contagem de consultas) um tanto difícil de integrar a uma suíte rspec (ou similar). Dito isso, algumas pessoas tentam
Estou curioso sobre quais outros métodos práticos, sugestões ou ideias as pessoas podem ter para adicionar testes de desempenho e comprovações de desempenho mais comumente disponíveis ao ecossistema Discourse. Ou se existem métodos ou abordagens que não mencionei aqui. Eu enfatizaria as palavras “prático” e “comumente disponível” aí.
Um pensamento que ocorre é que seria possível usar o MiniProfiler em um spec, ou seja, algo como Rack::MiniProfiler.profile_singleton_method. Mas eu nem tentei isso, nem sei se seria uma boa ideia.