Provavelmente, todos os usuários do Bazel já tiveram builds lentos ou mais lentos do que o esperado. Melhorar a performance de builds individuais tem um valor especial para metas com impacto significativo, como:
Metas principais de desenvolvedores que são iteradas e (re)criadas com frequência.
Bibliotecas comuns amplamente dependentes de outras metas.
Uma meta representativa de uma classe de metas (por exemplo, regras personalizadas), diagnosticar e corrigir problemas em um build pode ajudar a resolver problemas na escala maior.
Uma etapa importante para melhorar a performance dos builds é entender onde os recursos são gastos. Esta página lista diferentes métricas que podem ser coletadas. A análise da performance do build mostra como usar essas métricas para detectar e corrigir problemas de performance.
Há algumas maneiras principais de extrair métricas dos builds do Bazel, ou seja:
Build Event Protocol (BEP)
O Bazel gera vários buffers de protocolo
build_event_stream.proto
pelo Build Event Protocol (BEP), que
podem ser agregados por um back-end especificado por você. Dependendo dos seus casos de uso,
você pode agregar as métricas de várias maneiras, mas aqui vamos abordar
alguns conceitos e campos proto que seriam úteis em geral.
Comandos de consulta / cquery / aquery do Bazel
O Bazel oferece três modos de consulta diferentes (query, cquery e aquery) que permitem aos usuários consultar o gráfico de destino, o gráfico de destino configurado e o gráfico de ação respectivamente. A linguagem de consulta oferece um conjunto de funções utilizáveis nos diferentes modos de consulta, que permite personalizar as consultas de acordo com suas necessidades.
Perfis de trace JSON
Para cada invocação do Bazel semelhante a um build, o Bazel grava um perfil de trace no formato JSON O perfil de trace JSON pode ser muito útil para entender rapidamente em que o Bazel gastou tempo durante a invocação.
Registro de execução
O registro de execução pode ajudar a solucionar problemas e corrigir
acertos de cache remoto ausentes devido a diferenças de máquina e ambiente ou
ações não determinísticas. Se você transmitir a flag
--experimental_execution_log_spawn_metrics
(disponível no Bazel 5.2), ela também vai conter métricas detalhadas de geração, tanto para ações executadas
localmente quanto remotamente. Você pode usar essas métricas, por exemplo, para
fazer comparações entre a performance de máquinas locais e remotas ou para descobrir
qual parte da execução de geração é consistentemente mais lenta do que o esperado (por
exemplo, devido ao enfileiramento).
Registro do gráfico de execução
Embora o perfil de trace JSON contenha as informações do caminho crítico, às vezes
você precisa de mais informações sobre o gráfico de dependência das ações executadas.
A partir do Bazel 6.0, você pode transmitir as flags
--experimental_execution_graph_log e
--experimental_execution_graph_log_dep_type=all para gravar um registro sobre as
ações executadas e as interdependências delas.
Essas informações podem ser usadas para entender o arrasto adicionado por um nó no caminho crítico. O arrasto é a quantidade de tempo que pode ser salva removendo um nó específico do gráfico de execução.
Os dados ajudam a prever o impacto das mudanças no build e no gráfico de ações antes de realmente fazê-las.
Comparativo de mercado com o bazel-bench
O Bazel bench é uma ferramenta de comparativo de mercado para projetos do Git que compara a performance do build nos seguintes casos:
Comparativo de mercado do projeto:comparar dois commits do Git em uma única versão do Bazel. Usado para detectar regressões no build (geralmente por meio da adição de dependências).
Comparativo de mercado do Bazel: comparar duas versões do Bazel em um único commit do Git. Usado para detectar regressões no próprio Bazel (se você mantiver / fizer um fork do Bazel).
Os comparativos de mercado monitoram o tempo de parede, o tempo de CPU e o tempo do sistema, além do tamanho do heap retido do Bazel.
Também é recomendável executar o Bazel bench em máquinas físicas dedicadas que não estejam executando outros processos para reduzir as fontes de variabilidade.