Como Rastrear Referências na Integração Contínua com o Bencher
A maioria dos resultados de benchmark são efêmeros. Eles desaparecem assim que seu terminal atinge o limite de rolagem. Alguns frameworks de benchmark permitem armazenar em cache os resultados, mas a maioria apenas os faz localmente. O Bencher permite que você acompanhe seus benchmarks tanto de execuções locais quanto de CI e compare os resultados, enquanto ainda utiliza seu framework de benchmark favorito.
Existem três maneiras populares de comparar resultados de benchmark quando Benchmarking Contínuo, ou seja, benchmarking em CI:
- Benchmarking Contínuo Estatístico
- Acompanhe os resultados dos benchmarks ao longo do tempo para criar uma linha de base
- Use essa linha de base junto com Limiares Estatísticos para criar um limite estatístico
- Compare os novos resultados com esse limite estatístico para detectar regressões de desempenho
- Benchmarking Contínuo Relativo
- Execute os benchmarks para o código da linha de base atual
- Alterne para a nova versão do código
- Execute os benchmarks para a nova versão do código
- Use Limiares Percentuais para criar um limite para o código da linha de base
- Compare os resultados da nova versão do código com os da linha de base para detectar regressões de desempenho
- Detecção de Mudança de Ponto
- Ocasionalmente, execute os benchmarks para novas versões do código
- Use um algoritmo de detecção de mudança de ponto para detectar regressões de desempenho
- Faça bissecção para encontrar o commit que introduziu a regressão de desempenho
Benchmarking Contínuo Estatístico
Retomando de onde paramos nos tutoriais
Início Rápido e Docker Auto-hospedado,
vamos adicionar o Benchmarking Contínuo Estatístico ao nosso projeto Save Walter White
.
🐰 Certifique-se de ter criado um token de API e definido como a variável de ambiente
BENCHER_API_TOKEN
antes de continuar!
Agora estamos prontos para executar nossos benchmarks no CI. Como cada ambiente de CI é um pouco diferente, o exemplo a seguir é mais ilustrativo do que prático. Para exemplos mais específicos, consulte Benchmarking Contínuo no GitHub Actions e Benchmarking Contínuo no GitLab CI/CD.
Primeiro, precisamos criar e manter uma linha de base histórica para nosso branch main
ao realizar testes de benchmark a cada mudança no CI:
- Use o subcomando CLI
bencher run
para rodar os benchmarks do seu branchfeature-branch
. Veja o subcomando CLIbencher run
para uma visão geral completa. (ex:bencher run
) - Defina a opção
--project
para o slug do Projeto. Veja a documentação--project
para mais detalhes. (ex:--project save-walter-white-1234abcd
) - Defina a opção
--branch
para o nome do branch base. Veja a documentação de--branch
para uma visão geral completa. (ex:--branch main
) - Defina a opção
--testbed
para o nome do Testbed do corredor CI. Veja a documentação de--testbed
para mais detalhes. (ex:--testbed ci-runner
) - Defina o Limite para o Branch
main
, Testbedci-runner
e Medidalatency
:- Defina a opção
--threshold-measure
para a Medidalatency
incorporada que é gerada porbencher mock
. Veja a documentação--threshold-measure
para mais detalhes. (ex:--threshold-measure latency
) - Defina a opção
--threshold-test
para um teste t de Student (t_test
). Veja a documentação--threshold-test
para uma visão geral completa. (ex:--threshold-test t_test
) - Defina a opção
--threshold-max-sample-size
para o tamanho máximo da amostra de64
. Veja a documentação--threshold-max-sample-size
para mais detalhes. (ex:--threshold-max-sample-size 64
) - Defina a opção
--threshold-upper-boundary
para o Limite Superior de0.99
. Veja a documentação--threshold-upper-boundary
para mais detalhes. (ex:--threshold-upper-boundary 0.99
) - Configure o sinalizador
--thresholds-reset
para que apenas o Limite especificado esteja ativo. Veja a documentação--thresholds-reset
para uma visão geral completa. (ex:--thresholds-reset
)
- Defina a opção
- Defina o sinalizador
--err
para falhar o comando se um Alerta for gerado. Veja a documentação--err
para uma visão geral completa. (ex:--err
) - Defina a opção
--adapter
para Bencher Metric Format JSON (json
) que é gerado porbencher mock
. Veja adapters de estrutura de benchmark para uma visão geral completa. (ex:--adapter json
) - Especifique os argumentos do comando de benchmark.
Veja comando de benchmark para uma visão geral completa.
(ex:
bencher mock
)
A primeira vez que esse comando é executado no CI,
ele criará o Branch main
se ainda não existir.
O novo main
não terá um ponto de início ou dados existentes.
Um Limite será criado para o Branch main
, Testbed ci-runner
, e Medida latency
.
Em execuções subsequentes, novos dados serão adicionados ao Branch main
.
O Limite especificado será então usado para detectar regressões de desempenho.
Agora, estamos prontos para detectar regressões de desempenho no CI.
É assim que acompanharíamos o desempenho de um novo branch de funcionalidades no CI, apropriadamente chamado feature-branch
:
- Use o subcomando CLI
bencher run
para rodar os benchmarks do seu branchfeature-branch
. Veja o subcomando CLIbencher run
para uma visão geral completa. (ex:bencher run
) - Defina a opção
--project
para o slug do Projeto. Veja a documentação--project
para mais detalhes. (ex:--project save-walter-white-1234abcd
) - Defina a opção
--branch
para o nome do Branch de funcionalidade. Veja a documentação de--branch
para uma visão geral completa. (ex:--branch feature-branch
) - Configure o Ponto de Início para o Branch
feature-branch
:- Defina a opção
--start-point
para o ponto de início do Branch de funcionalidades. Veja a documentação--start-point
para uma visão geral completa. (ex:--start-point main
) - Defina a opção
--start-point-hash
para ogit
hash do ponto de início do Branch de funcionalidades. Veja a documentação--start-point-hash
para uma visão geral completa. (ex:--start-point-hash 32ae...dd8b
) - Configure o sinalizador
--start-point-clone-thresholds
para clonar os Limites a partir do ponto de início. Veja a documentação--start-point-clone-thresholds
para uma visão geral completa. (ex:--start-point-clone-thresholds
) - Configure o sinalizador
--start-point-reset
para sempre redefinir o Branch para o ponto de início. Isso evitará desvio de dados de benchmark. Veja a documentação--start-point-reset
para uma visão geral completa. (ex:--start-point-reset
)
- Defina a opção
- Defina a opção
--testbed
para o nome do Testbed. Veja a documentação de--tested
para mais detalhes. (ex:--testbed ci-runner
) - Defina o sinalizador
--err
para falhar o comando se um Alerta for gerado. Veja a documentação--err
para uma visão geral completa. (ex:--err
) - Defina a opção
--adapter
para Bencher Metric Format JSON (json
) que é gerado porbencher mock
. Veja adapters de estrutura de benchmark para uma visão geral completa. (ex:--adapter json
) - Especifique os argumentos do comando de benchmark.
Veja comando de benchmark para uma visão geral completa.
(ex:
bencher mock
)
A primeira vez que esse comando é executado no CI,
Bencher criará o Branch feature-branch
já que ele ainda não existe.
O novo feature-branch
usará o Branch main
no hash 32aea434d751648726097ed3ac760b57107edd8b
como seu ponto de início.
Isso significa que o feature-branch
terá uma cópia de todos os dados e Limites
do Branch main
para comparar os resultados de bencher mock
.
Em todas as execuções subsequentes, o Bencher irá redefinir o Branch feature-branch
para o ponto de início,
e usará os dados e Limites do Branch main
para detectar regressões de desempenho.
Benchmarking Contínuo Relativo
Retomando de onde paramos nos tutoriais
Início Rápido e Autohospedagem com Docker,
vamos adicionar o Benchmarking Contínuo Relativo ao nosso projeto Save Walter White
.
🐰 Certifique-se de criar um token de API e configurá-lo como a variável de ambiente
BENCHER_API_TOKEN
antes de continuar!
O Benchmarking Contínuo Relativo executa uma comparação lado a lado de duas versões do seu código.
Isso pode ser útil ao lidar com ambientes CI/CD ruidosos,
onde os recursos disponíveis podem variar bastante entre as execuções.
Neste exemplo, vamos comparar os resultados da execução no branch main
com os resultados da execução em um branch de feature, convenientemente chamado feature-branch
.
Como cada ambiente de CI é um pouco diferente,
o exemplo a seguir é mais ilustrativo que prático.
Para exemplos mais específicos, veja Benchmarking Contínuo em GitHub Actions
e Benchmarking Contínuo em GitLab CI/CD.
Primeiro, precisamos fazer checkout do branch main
com git
no CI:
Depois, precisamos executar nossos benchmarks no branch main
no CI:
- Use o subcomando da CLI
bencher run
para executar os benchmarks do seu branchmain
. Veja uma visão geral completa do subcomandobencher run
da CLI. (ex:bencher run
) - Configure a opção
--project
para o slug do Projeto. Veja os documentos da opção--project
para mais detalhes. (ex:--project save-walter-white-1234abcd
) - Configure a opção
--branch
para o nome do branch base. Veja uma visão geral completa dos documentos da opção--branch
. (ex:--branch main
) - Configure o sinalizador
--start-point-reset
para sempre redefinir o branch base. Isso garantirá que todos os dados de benchmark sejam do runner do CI atual. Veja uma visão geral completa dos documentos do--start-point-reset
. (ex:--start-point-reset
) - Configure a opção
--testbed
para o nome do Testbed do runner do CI. Veja os documentos da opção--testbed
para mais detalhes. (ex:--testbed ci-runner
) - Configure a opção
--adapter
para Bencher Metric Format JSON (json
) que é gerado porbencher mock
. Veja uma visão geral completa dos adaptadores de harness de benchmark. (ex:--adapter json
) - Especifique os argumentos de comando do benchmark.
Veja uma visão geral completa dos comandos de benchmark.
(ex:
bencher mock
)
A primeira vez que este comando for executado no CI,
ele criará o branch feature-branch
já que ainda não existe.
O novo feature-branch
não terá um ponto de início, dados existentes ou Limiares.
Nos execuções subsequentes, o Head antigo do feature-branch
será substituído
e um novo Head para o feature-branch
será criado sem um ponto de início, dados existentes ou Limiares.
Em seguida, precisamos fazer checkout do branch feature-branch
com git
no CI:
Por fim, estamos prontos para executar nossos benchmarks de feature-branch
no CI:
- Use o subcomando da CLI
bencher run
para executar seus benchmarks defeature-branch
. Veja uma visão geral completa do subcomandobencher run
da CLI. (ex:bencher run
) - Configure a opção
--project
para o slug do Projeto. Veja os documentos da opção--project
para mais detalhes. (ex:--project save-walter-white-1234abcd
) - Configure a opção
--branch
para o nome do branch de feature. Veja uma visão geral completa dos documentos da opção--branch
. (ex:--branch feature-branch
) - Configure o Ponto de Início para o branch
feature-branch
:- Configure a opção
--start-point
para o ponto de início do branch de feature. Veja uma visão geral completa dos documentos do--start-point
. (ex:--start-point main
) - Configure o sinalizador
--start-point-reset
para sempre redefinir o branch para o ponto de início. Isso usará apenas os resultados mais recentes do benchmark relativo. Veja uma visão geral completa dos documentos do--start-point-reset
. (ex:--start-point-reset
)
- Configure a opção
- Configure a opção
--testbed
para o nome do Testbed do runner do CI. Veja os documentos da opção--testbed
para mais detalhes. (ex:--testbed ci-runner
) - Configure o Limite para o branch
feature-branch
, Testbedci-runner
e Medidalatency
:- Configure a opção
--threshold-measure
para a Medidalatency
incorporada que é gerada porbencher mock
. Veja mais detalhes dos documentos da opção--threshold-measure
. (ex:--threshold-measure latency
) - Configure a opção
--threshold-test
para uma porcentagem básica (percentage
). Veja uma visão geral completa dos documentos da opção--threshold-test
. (ex:--threshold-test percentage
) - Configure a opção
--threshold-upper-boundary
para o Limite Superior de0.25
. Veja mais detalhes dos documentos da opção--threshold-upper-boundary
. (ex:--threshold-upper-boundary 0.25
) - Configure o sinalizador
--thresholds-reset
para que apenas o Limite especificado fique ativo. Veja uma visão geral completa dos documentos do--thresholds-reset
. (ex:--thresholds-reset
)
- Configure a opção
- Configure o sinalizador
--err
para falhar o comando se um Alerta for gerado. Veja uma visão geral completa dos documentos do--err
. (ex:--err
) - Configure a opção
--adapter
para Bencher Metric Format JSON (json
) que é gerado porbencher mock
. Veja uma visão geral completa dos adaptadores de harness de benchmark. (ex:--adapter json
) - Especifique os argumentos de comando do benchmark.
Veja uma visão geral completa dos comandos de benchmark.
(ex:
bencher mock
)
Toda vez que este comando for executado no CI,
ele estará comparando os resultados do feature-branch
com apenas os resultados mais recentes do main
.
O Limite especificado é então usado para detectar regressões de desempenho.
Detecção de Punto de Mudança
A Detecção de Punto de Mudança usa um algoritmo de ponto de mudança para avaliar uma grande janela de resultados recentes. Isso permite que o algoritmo ignore outliers como ruído e produza menos falsos positivos. Embora a Detecção de Punto de Mudança seja considerada benchmarking contínuo, ela não permite detectar regressão de desempenho em CI. Ou seja, você não pode detectar uma regressão de desempenho antes de um branch de feature ser mesclado. Isso é algumas vezes referido como detecção “fora de banda”.
Por exemplo, se você tem um benchmark bench_my_critical_path
, e ele teve as seguintes latências históricas: 5 ms
, 6 ms
, 5 ms
, 5ms
, 7ms
.
Se o próximo resultado do benchmark fosse 11 ms
, então um limite de Benchmarking Contínuo Estatístico e o algoritmo de Detecção de Punto de Mudança interpretariam as coisas de maneira muito diferente. O limite provavelmente seria excedido e um alerta seria gerado. Se essa execução do benchmark estivesse vinculada a um pull request, a build provavelmente seria configurada para falhar devido a esse alerta. No entanto, o algoritmo de ponto de mudança não faria nada… ainda. Se na próxima execução as coisas caíssem de volta para 5 ms
, provavelmente não geraria um alerta. Por outro lado, se na próxima ou duas próximas rodadas resultassem em 10 ms
e 12 ms
, somente então o algoritmo de ponto de mudança acionaria um alerta.
Você está interessado em usar Detecção de Punto de Mudança com Bencher? Se sim, por favor, deixe um comentário na issue de acompanhamento ou entre em contato diretamente conosco.
🐰 Parabéns! Você aprendeu como rastrear referências na Integração Contínua com o Bencher! 🎉