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:
Principais destinos de desenvolvedores que são frequentemente iterados e (re)criados.
Bibliotecas comuns amplamente dependentes de outros alvos.
Uma segmentação representativa de uma classe de segmentações (por exemplo, regras personalizadas) o diagnóstico e a correção de problemas em um build podem ajudar a resolver em maior escala.
Uma etapa importante para melhorar o desempenho dos builds é entender onde 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 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
podem ser agregadas por um back-end especificado por você. Dependendo dos casos de uso,
você pode decidir agregar as métricas de várias maneiras, mas aqui vamos
alguns conceitos e campos proto que seriam úteis de forma geral.
Comandos query / cquery / aquery do Bazel
O Bazel oferece três modos de consulta diferentes: query, cquery e aquery) que permitem aos usuários para consultar o gráfico de destino, o gráfico de destino configurado e o gráfico de ações 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 trace JSON pode muito útil para entender rapidamente em que o Bazel passou o 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ê passar a sinalização
--experimental_execution_log_spawn_metrics
(disponível no Bazel 5.2), ele também contém métricas detalhadas de geração, tanto 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 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 o
as ações executadas e as interdependências deles.
Essas informações podem ser usadas para entender a ação de arrastar que é adicionada por um nó 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.
Comparativo de mercado com o bazel-bench
O Bazel bench é ferramenta de comparativo de mercado para projetos Git para comparar o desempenho do build no seguintes casos:
Comparativo de mercado do projeto: comparativo de mercado de dois commits 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.