Provavelmente, todos os usuários do Bazel tiveram builds lentos ou mais lentos do que o previsto. Melhorar o desempenho de builds individuais tem um valor específico para destinos com impacto significativo, como:
Principais destinos de desenvolvedores que são frequentemente iterados e (re)criados.
Bibliotecas comuns amplamente dependentes de outros alvos.
Um destino representativo de uma classe de destinos (por exemplo, regras personalizadas), diagnosticar e corrigir problemas em um build pode ajudar a resolver problemas em maior escala.
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. Detalhar 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 builds do Bazel:
Protocolo de evento de build (BEP)
O Bazel gera uma variedade de 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 examinar alguns conceitos e campos proto que seriam úteis de modo geral a serem considerados.
Comandos query / cquery / aquery do Bazel
O Bazel fornece três modos 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ções, respectivamente. A linguagem de consulta oferece um conjunto de funções utilizáveis nos diferentes modos de consulta, permitindo que você personalize as consultas de acordo com suas necessidades.
Perfis de trace JSON
Para cada invocação do Bazel semelhante a uma versão, o Bazel grava um perfil de rastreamento no formato JSON. O perfil de rastreamento JSON pode ser muito útil para entender rapidamente em que o Bazel passou tempo durante a invocação.
Registro de execução
O registro de execução pode ajudar a solucionar problemas e corrigir ocorrências em 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 para
ações executadas local e remotamente. É possível usar essas métricas, por exemplo, para fazer comparações entre o desempenho da máquina local e remota ou descobrir qual parte da execução da geração é consistentemente mais lenta do que o esperado (por exemplo, devido à fila).
Registro do gráfico de execução
O perfil de rastreamento JSON contém as informações do caminho crítico, mas à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, é 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 a ação de arrastar adicionada por um nó no caminho crítico. A ação de arrastar é o tempo que pode ser economizado removendo um nó específico do gráfico de execução.
Os dados ajudam a prever o impacto das mudanças no gráfico de ação e build antes de realizá-las.
Comparação com o bazel-bench
O Bazel bench (link em inglês) é uma ferramenta para que projetos Git comparem o desempenho do build nos seguintes casos:
Comparativo de mercado do projeto:comparação entre duas confirmações do git em uma única versão do Bazel. Usado para detectar regressões no seu build, geralmente pela adição de dependências.
Comparativo de mercado do Bazel:comparação de duas versões do Bazel em uma única confirmação do git. Usado para detectar regressões no próprio Bazel (se você mantiver / bifurcar o Bazel).
Os comparativos de mercado monitoram o tempo decorrido, o tempo de CPU e o tempo do sistema, além do tamanho do heap retido do Bazel.
Também é recomendável executar o banco de dados do Bazel em máquinas físicas dedicadas que não estão executando outros processos para reduzir as fontes de variabilidade.