É provável que todos os usuários do Bazel tenham passado por 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 do desenvolvedor que são frequentemente iterados e (re)criados.
Bibliotecas comuns muito 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 uma escala maior.
Uma etapa importante para melhorar o desempenho dos builds é entender onde os recursos são gastos. Esta página lista diferentes métricas que você pode coletar. Detalhamento do 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 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 casos de uso, é possível agregar as métricas de várias maneiras, mas aqui vamos analisar alguns conceitos e campos proto que podem ser úteis em geral.
Comandos query / cquery / aquery do Bazel
O Bazel fornece três modos diferentes de consulta (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 fornece um pacote de funções que podem ser usadas em diferentes modos, permitindo que você personalize as consultas de acordo com suas necessidades.
Perfis do Trace JSON
Para cada invocação do Bazel semelhante a um build, ele grava um perfil de rastreamento no formato JSON. O perfil de rastro JSON pode ser muito útil para entender rapidamente o tempo gasto pelo Bazel 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 sinalização
--experimental_execution_log_spawn_metrics
(disponível no Bazel 5.2), ela também conterá métricas detalhadas de geração, tanto para
ações executadas local quanto remotamente. É possível usar essas métricas, por exemplo, para fazer comparações entre o desempenho 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 rastreamento 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, é possível transmitir as sinalizações
--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 que é adicionado por um nó no caminho crítico. A ação de arrastar é a quantidade de tempo que pode ser economizada ao remover um nó específico do gráfico de execução.
Os dados ajudam a prever o impacto das alterações no gráfico de criação e ação antes que você as faça.
Como fazer comparações com o bazel-bench
O Bazel bench é uma ferramenta de comparação para projetos do Git para comparar o desempenho do build nos seguintes casos:
Comparativo de mercado do projeto:comparação de duas confirmações 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:comparação de duas versões do Bazel entre si em uma única confirmação do git. Usado para detectar regressões no próprio Bazel (se você manter / bifurcar o Bazel).
As comparações monitoram o tempo decorrido, o tempo de CPU e o tempo do sistema e o tamanho do heap retido do Bazel.
Também é recomendável executar o banco do Bazel em máquinas físicas dedicadas que não estejam executando outros processos para reduzir as fontes de variabilidade.