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 eles 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 de 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 do relógio. Ao realizar benchmarking contínuo, essa volatilidade adiciona ruído indesejado aos resultados.
Existem algumas opções para lidar com isso:
- Benchmarking Relativo
- Runners de CI dedicados
- Mudança de arneses de benchmarking para um que conta instruções ao invés do tempo do relógio
Ou simplesmente aceite o caos! O benchmarking contínuo não precisa ser perfeito. Sim, a redução da volatilidade e, assim, do ruído no seu ambiente de benchmarking contínuo permitirá que você detecte regresões de desempenho cada vez mais finas. No entanto, não deixe que o perfeito seja inimigo do bom aqui!
Você pode olhar para este gráfico e pensar, “Uau, isso é loucura!” Mas pergunte a si mesmo, seu atual processo de desenvolvimento pode detectar uma regressão de desempenho de dois ou mesmo dez vezes antes que afete seus usuários? Provavelmente não! E isso sim é loucura!
Mesmo com todo o ruído de um ambiente CI, rastrear benchmarks de tempo de relógio ainda pode render grandes dividendos ao detectar regressões de desempenho antes que elas atinjam seus clientes em produção. Com o tempo, à medida que o gerenciamento de desempenho de seu software amadurece, você pode construir a partir daí. Enquanto isso, apenas use seu CI regular.
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 nenhuma 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 funcionar em paralelo precisarão ser paralelizadas. No entanto, a maioria das cargas de trabalho precisa ser executada em série, e simplesmente jogar mais computação 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:
- Rastrear benchmarks em várias linguagens
- Ingere sem problemas a saída padrão do arnês de benchmark de linguagem
- Extensível para uma saída personalizada do arnês de benchmark
- Código aberto e capaz de hospedar por conta própria
- Funciona com vários hosts de CI
- Autenticação e autorização do usuário
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 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, eles entendem a importância de monitorar o desempenho durante o desenvolvimento e integrar essas percepções ao processo de desenvolvimento através de CB. Nós construímos o Bencher para trazer o benchmarking contínuo de trás das paredes das grandes empresas de tecnologia para a comunidade de código aberto. Para links para posts relacionados ao benchmarking contínuo de Grandes Empresas de Tecnologia, veja a arte anterior.
Bencher: Benchmarking Contínuo
Bencher é um conjunto de ferramentas de benchmarking contínuas. 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 cheguem à produção.
- Execute: Execute seus benchmarks localmente ou no CI usando suas ferramentas de benchmarking favoritas. O CLI
benchersimplesmente envolve seu harness de benchmark existente 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 no CI. Bencher usa análises personalizáveis e de última geração para detectar regressões de desempenho antes que elas cheguem à produção.
Pelos mesmos motivos que os testes de unidade são executados no CI para prevenir regressões de funcionalidades, benchmarks deveriam ser executados no CI com o Bencher para prevenir regressões de desempenho. Bugs de desempenho são bugs!
Comece a capturar regressões de desempenho no CI — experimente o Bencher Cloud gratuitamente.
Benchmarking Contínuo vs Comparação Local de Benchmark
Existem vários suportes 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 CB.
Existem vários recursos que o Bencher oferece que as ferramentas de comparação local de benchmark não podem:
- Comparação do mesmo benchmark entre diferentes bancos de teste
- Comparação de benchmarks em diferentes idiomas e suportes
- 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, 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 os custos diretos de corrigir os defeitos quanto os 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 que as ferramentas APM não oferecem:
- Detectar e prevenir regressões de desempenho antes de chegarem à produção
- Mudanças de desempenho e impactos incluídos na revisão do código
- Sem sobrecarga em ambientes de produção
- Eficaz para implementações no local
- 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)
Benchmarking Contínuo (CB) é complementar à Integração Contínua (CI). Pelos mesmos motivos que os testes unitários são executados no CI para cada modificação no código, testes de desempenho deveriam ser executados no CB para cada modificaçã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 continuou no domínio dos testes de desempenho. Atualmente, a ferramenta 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, resultando em melhor ferramental para criar e executar testes de desempenho, resultando em um conjunto de testes que é sustentável e pode ser testado.
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 |
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 pode ser usado para medir quanto tempo leva para servir uma casquinha de sorvete (micro-benchmark), e o benchmarking também pode 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.