O que é Benchmarking Contínuo?
O Benchmarking Contínuo é uma prática de desenvolvimento de software onde os membros de uma equipe avaliam seu trabalho com frequência, geralmente cada pessoa faz benchmarks pelo menos diariamente - resultando em múltiplos benchmarks por dia. Cada benchmark é verificado por uma compilação automatizada para detectar regressões de desempenho o mais rápido possível. Muitas equipes descobrem que esta abordagem leva a uma redução significativa nas regressões de desempenho e permite que uma equipe desenvolva um software de alta performance de forma mais rápida.
Hoje, todos na indústria de software estão cientes da Integração Contínua (CI). Em um nível fundamental, CI é sobre detectar e prevenir regressões de recursos de software antes que elas cheguem à produção. Da mesma forma, o Benchmarking Contínuo (CB) é sobre detectar e prevenir regressões de desempenho de software antes que elas cheguem à produção. Pelas mesmas razões que os testes de unidade são executados em CI para cada alteração de código, testes de desempenho devem ser executados em CB para cada alteração de código. Esta analogia é de fato tão apta, que o primeiro parágrafo desta seção é apenas uma versão do Mad Libs da introdução de Martin Fowler à Integração Contínua em 2006.
🐰 Bugs de desempenho são bugs!
Benchmarking em CI
Mito: Você não pode executar benchmarks em CI
A maioria dos arneses de benchmarking usa o relógio do sistema para medir latência ou taxa de transferência. Isso é muito útil, pois são exatamente essas as métricas que, como desenvolvedores, mais nos importamos. No entanto, ambientes de CI de propósito geral costumam ser barulhentos e inconsistentes ao medir o tempo de relógio. Ao realizar Benchmarking Contínuo, essa volatilidade adiciona ruído indesejado aos resultados.
Existem algumas opções para lidar com isso:
- Executores em Hardware Dedicado
- Benchmarking Contínuo Relativo
- Mudar para um arnês de benchmarking que conta instruções ao invés do tempo de relógio
De longe, os Executores em Hardware Dedicado são a melhor opção em praticamente todos os casos. O Bencher oferece Executores em Hardware Dedicado com menos de 2% de variação. Compare isso com os Executores de GitHub Actions, que podem apresentar mais de 30% de variação entre execuções. Reduzir a volatilidade e, portanto, o ruído no seu ambiente de Benchmarking Contínuo permitirá que você detecte regressões de desempenho cada vez mais sutis.
Desempenho Importa
Mito: Você não consegue perceber 100ms de latência
É comum ouvir pessoas afirmarem que os humanos não conseguem perceber 100ms de latência. Um artigo do Nielsen Group sobre tempos de resposta é frequentemente citado para essa alegação.
0,1 segundo é aproximadamente o limite para que o usuário sinta que o sistema está reagindo instantaneamente, o que significa que nenhum feedback especial é necessário, exceto para exibir o resultado.
- Jakob Nielsen, 1 Jan 1993
Mas isso simplesmente não é verdade.
Em algumas tarefas, as pessoas podem perceber apenas 2ms de latência.
Uma maneira fácil de provar isso é um experimento de Dan Luu: abra seu terminal e execute sleep 0; echo "ping" e depois execute sleep 0.1; echo "pong". Você notou a diferença, certo‽
Outro ponto comum de confusão é a distinção entre a percepção de latência e os tempos de reação humana. Mesmo que leve cerca de 200ms para responder a um estímulo visual, isso é independente da percepção do evento em si. Por analogia, você pode notar que seu trem está dois minutos atrasado (latência percebida) mesmo que a viagem de trem leve duas horas (tempo de reação).
Desempenho importa! Desempenho é uma característica!
- Cada 100ms mais rápido → 1% mais conversões (Mobify, ganhando +$380.000/ano)
- 50% mais rápido → 12% mais vendas (AutoAnything)
- 20% mais rápido → 10% mais conversões (Furniture Village)
- 40% mais rápido → 15% mais cadastros (Pinterest)
- 850ms mais rápido → 7% mais conversões (COOK)
- Cada 1 segundo mais lento → 10% menos usuários (BBC)
Com o fim da Lei de Moore, as cargas de trabalho que podem ser executadas em paralelo precisarão ser paralelizadas. No entanto, a maioria das cargas de trabalho precisa ser executada em série, e simplesmente jogar mais poder computacional no problema está rapidamente se tornando uma solução incontrolável e cara.
O Benchmarking Contínuo é um componente chave para desenvolver e manter um software moderno performante diante desta mudança.
Ferramentas de Benchmarking Contínuo
Antes de criar o Bencher, procuramos uma ferramenta que pudesse:
- Executar benchmarks no exato mesmo hardware dedicado, tanto localmente quanto em CI
- Rastrear benchmarks em várias linguagens
- Ingerir sem problemas a saída padrão do arnês de benchmark da linguagem
- Ser extensível para saídas personalizadas de arnês de benchmark
- Código aberto e capaz de ser auto-hospedado
- Funcionar com múltiplos hosts de CI
- Autenticação e autorização de usuários
Infelizmente, nada que atendesse a todos esses critérios existia. Veja a arte anterior para uma lista abrangente das ferramentas de benchmarking existentes que nos inspiraram.
Benchmarking Contínuo Fora do CI
O CI deve ser uma verificação final, não o único lugar onde os testes são realizados. O Bencher é a primeira ferramenta de Benchmarking Contínuo a permitir que você execute seus benchmarks no exato mesmo hardware dedicado, tanto localmente quanto em CI. Isso permite que desenvolvedores e agentes comparem seu trabalho local em andamento com qualquer ponto do histórico de desempenho do projeto.
Ao executar em hardware local, o Bencher em Hardware Dedicado permite que você continue multitarefando. Não é preciso parar tudo o mais no seu sistema, obter uma branch antiga e executar uma comparação.
Ao executar em um ambiente de nuvem, o Bencher em Hardware Dedicado permite que você confie nos resultados. Sem se preocupar com vizinhos barulhentos, estrangulamento (throttling) ou trocas de host no meio da execução.
Benchmarking Contínuo em Grandes Empresas de Tecnologia
Ferramentas como o Bencher foram desenvolvidas internamente na Microsoft, Facebook (agora Meta), Apple, Amazon, Netflix e Google, entre inúmeras outras. Como titãs da indústria, elas entendem a importância de monitorar o desempenho durante o desenvolvimento e integrar essas percepções ao processo de desenvolvimento através do Benchmarking Contínuo. Construímos o Bencher para trazer o Benchmarking Contínuo de trás das muralhas das Grandes Empresas de Tecnologia para a comunidade de código aberto. Para links de posts relacionados ao Benchmarking Contínuo nas Grandes Empresas de Tecnologia, veja a arte anterior.
Bencher: Benchmarking Contínuo
Bencher é um conjunto de ferramentas de benchmarking contínuo. Já teve algum impacto de regressão de desempenho nos seus usuários? Bencher poderia ter prevenido isso. Bencher permite que você detecte e previna regressões de desempenho antes que sejam mescladas.
- Execute: Execute seus benchmarks localmente ou no CI usando os exatos mesmos runners bare metal e suas ferramentas de benchmarking favoritas. O CLI
bencherorquestra a execução dos seus benchmarks em bare metal e armazena seus resultados. - Rastreie: Acompanhe os resultados de seus benchmarks ao longo do tempo. Monitore, consulte e faça gráficos dos resultados usando o console web do Bencher baseado na branch de origem, testbed e medida.
- Capture: Capture regressões de desempenho localmente ou no CI usando o exato mesmo hardware bare metal. Bencher usa análises personalizáveis e de última geração para detectar regressões de desempenho antes que sejam mescladas.
Pelos mesmos motivos que os testes de unidade são executados para prevenir regressões de funcionalidades, benchmarks deveriam ser executados com o Bencher para prevenir regressões de desempenho. Bugs de desempenho são bugs!
Comece a capturar regressões de desempenho — experimente o Bencher Cloud gratuitamente.
Benchmarking Contínuo vs Comparação Local de Benchmark
Existem vários arneses de benchmark que permitem comparar resultados localmente. A comparação local é ótima para iterações rápidas ao ajustar o desempenho. No entanto, não se deve confiar nela para detectar regressões de desempenho de forma contínua. Assim como ser capaz de executar testes unitários localmente não elimina a necessidade de CI, ser capaz de executar e comparar benchmarks localmente não elimina a necessidade de Benchmarking Contínuo.
Existem vários recursos que o Bencher oferece e que as ferramentas de comparação local de benchmark não oferecem:
- Comparação do mesmo benchmark entre diferentes bancos de teste
- Comparação de benchmarks entre diferentes linguagens e arneses
- Colaboração e compartilhamento de resultados de benchmark
- Execução de benchmarks em bancos de teste dedicados para minimizar o ruído
- Acabou o copypasta
Benchmarking Contínuo vs Gestão de Desempenho de Aplicação (APM)
A Gestão de Desempenho de Aplicação (APM) é uma ferramenta vital para os serviços de software modernos. No entanto, o APM é projetado para ser usado em produção. Quando uma regressão de desempenho é detectada, ela já está afetando seus clientes.
A maioria dos defeitos acaba custando mais do que teria custado para preveni-los. Defeitos são caros quando ocorrem, tanto pelos custos diretos de corrigir os defeitos quanto pelos custos indiretos devido a relacionamentos danificados, negócios perdidos e tempo de desenvolvimento perdido.
— Kent Beck, Extreme Programming Explained
Existem vários recursos que o Bencher oferece e que as ferramentas de APM não oferecem:
- Detectar regressões de desempenho antes de serem mescladas
- Mudanças e impactos de desempenho incluídos na revisão de código
- Sem sobrecarga em ambientes de produção
- Eficaz para implantações on-premises
- Sem alterações no código-fonte de produção
Benchmarking Contínuo vs Observabilidade
Uma rosa com qualquer outro nome teria o mesmo cheiro doce. Veja Benchmarking Contínuo vs Gestão de Desempenho de Aplicação acima.
Benchmarking Contínuo vs Integração Contínua (CI)
O Benchmarking Contínuo (CB) é complementar à Integração Contínua (CI). Pelas mesmas razões que os testes unitários são executados em CI para cada alteração de código, os testes de desempenho devem ser executados em CB para cada alteração de código.
Enquanto os testes unitários e de aceitação são amplamente adotados como práticas padrão de desenvolvimento, esta tendência não se estendeu ao domínio dos testes de desempenho. Atualmente, o ferramental comum leva os testadores a criar códigos descartáveis e uma mentalidade de clique-e-script. Tratar os testes de desempenho como um cidadão de primeira classe permite a criação de testes melhores que cobrem mais funcionalidades, levando a um ferramental melhor para criar e executar testes de desempenho, resultando em uma suíte de testes que é sustentável e pode ser testada por si mesma.
Benchmarking Contínuo vs Testes de Carga Contínuos
Para entender a diferença entre Benchmarking Contínuo e Testes de Carga Contínuos, você precisa entender a diferença entre benchmarking e testes de carga.
| Tipo de Teste | Escopo do Teste | Usuários do Teste |
|---|---|---|
| Benchmarking | Função - Serviço | Um - Muitos |
| Teste de Carga | Serviço | Muitos |
O benchmarking pode testar o desempenho do software desde o nível de função (micro-benchmarks) até o nível de serviço (macro-benchmarks). Os benchmarks são ótimos para testar o desempenho de uma parte específica do seu código de forma isolada. Os testes de carga apenas testam o desempenho do software ao nível de serviço e simulam múltiplos usuários concorrentes. Os testes de carga são ótimos para testar o desempenho do serviço inteiro sob uma carga específica.
🍦 Imagine que queremos acompanhar o desempenho de um carrinho de sorvete. O benchmarking poderia ser usado para medir quanto tempo leva para servir uma casquinha de sorvete (micro-benchmark), e o benchmarking também poderia ser usado para medir quanto tempo leva para um único cliente pedir, receber seu sorvete e pagar (macro-benchmark). Os testes de carga poderiam ser usados para ver como o carrinho de sorvete atende 100 clientes num dia quente de verão.