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 do desenvolvedor que são iteradas e (re)criadas com frequência.
Bibliotecas comuns com dependência de outros alvos.
Um destino representativo de uma classe de destinos (por exemplo, regras personalizadas), diagnosticando e corrigindo problemas em um build, pode ajudar a resolver problemas em escala maior.
Uma etapa importante para melhorar o desempenho dos builds é entender onde os recursos são gastos. Esta página lista as diferentes métricas que você pode coletar. Como analisar o desempenho do build mostra como usar essas métricas para detectar e corrigir problemas de desempenho do build.
Há algumas maneiras principais de extrair métricas dos seus builds do Bazel:
Build Event Protocol (BEP)
O Bazel gera vários buffers de protocolo
build_event_stream.proto
usando o Build Event Protocol (BEP), que
pode ser agregado por um back-end especificado por você. Dependendo dos seus casos de uso,
você pode decidir agregar as métricas de várias maneiras, mas aqui vamos abordar
alguns conceitos e campos proto que seriam úteis em geral.
Comandos query / cquery / aquery do Bazel
O Bazel oferece três modos de consulta diferentes (query, cquery e aquery) que permitem que os usuários consultem o gráfico de destino, o gráfico de destino configurado e o gráfico de ação, respectivamente. A linguagem de consulta fornece um pacote de funções que podem ser usadas nos diferentes modos de consulta, permitindo personalizar as consultas de acordo com suas necessidades.
Perfis de rastreamento JSON
Para cada invocação do Bazel semelhante a um build, o Bazel grava um perfil de rastreamento no formato JSON. O perfil de rastro 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 você a resolver problemas e corrigir
a ausência de acertos de cache remoto 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 de criação detalhadas, tanto para
ações executadas localmente quanto remotamente. É possível usar essas métricas, por exemplo, para
fazer comparações entre o desempenho da máquina local e remota ou para descobrir
qual parte da execução de criação é consistentemente mais lenta do que o esperado (por
exemplo, devido à fila).
Registro do gráfico de execução
Embora o perfil de rastreamento JSON contenha as informações do caminho crítico, às vezes
é necessário mais informações sobre o gráfico de dependência das ações executadas.
A partir do Bazel 6.0, é possível 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 economizada 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 fazer isso.
Comparativo de mercado com o bazel-bench
O Bazel bench é uma ferramenta de comparação de mercado para projetos do Git para comparar a performance de build nos seguintes casos:
Comparativo de mercado do projeto:comparativo de mercado de duas transações do git em uma única versão do Bazel. Usado para detectar regressões no build (geralmente pela adição de dependências).
Comparativo de mercado do Bazel:compara duas versões do Bazel uma com a outra em um único commit do Git. Usado para detectar regressões no próprio Bazel (se você manter / bifurcar o Bazel).
Os comparativos de mercado monitoram o tempo de parede, o tempo da CPU e o tempo do sistema e o tamanho da pilha retida do Bazel.
Também é recomendável executar o banco de testes do Bazel em máquinas físicas dedicadas que não estejam executando outros processos para reduzir as fontes de variabilidade.