Se usó la API de Cloud Translation para traducir esta página.

Desglose del rendimiento de la compilación

Bazel es complejo y realiza muchas tareas diferentes a lo largo de una compilación, algunas de las cuales pueden tener un impacto en el rendimiento de la compilación. En esta página, se intenta asignar algunos de estos conceptos de Bazel a sus implicaciones en el rendimiento de la compilación. Si bien no es exhaustiva, incluimos algunos ejemplos de cómo detectar problemas de rendimiento de compilación mediante la extracción de métricas y lo que puedes hacer para corregirlos. Con esto, esperamos que puedas aplicar estos conceptos cuando investigues regresiones de rendimiento de compilación.

Compilaciones limpias e incrementales

Una compilación limpia es una que compila todo desde cero, mientras que una compilación incremental reutiliza un trabajo ya completado.

Te sugerimos buscar las compilaciones incrementales y limpias por separado, en especial cuando recopilas o agregas métricas que dependen del estado de las cachés de Bazel (por ejemplo, las métricas de tamaño de la solicitud de compilación). También representan dos experiencias del usuario diferentes. En comparación con iniciar una compilación limpia desde cero (que tarda más debido a una caché fría), las compilaciones incrementales ocurren con mayor frecuencia a medida que los desarrolladores iteran en el código (por lo general, más rápido, ya que la caché ya suele estar caliente).

Puedes usar el campo CumulativeMetrics.num_analyses en el BEP para clasificar las compilaciones. Si es num_analyses <= 1, es una compilación limpia; de lo contrario, podemos categorizarla en términos generales como una compilación incremental. El usuario podría haber cambiado a diferentes marcas o a distintos objetivos, lo que provoca una compilación limpia de forma eficaz. Es probable que cualquier definición más rigurosa de incrementalidad tenga que presentarse en forma de heurística, por ejemplo, mirar la cantidad de paquetes cargados (PackageMetrics.packages_loaded).

Métricas de compilación deterministas como proxy para el rendimiento de la compilación

Medir el rendimiento de compilación puede ser difícil debido a la naturaleza no determinista de ciertas métricas (por ejemplo, el tiempo de CPU de Bazel o los tiempos de cola en un clúster remoto). Por lo tanto, puede ser útil usar métricas deterministas como proxy para la cantidad de trabajo que realiza Bazel, lo que, a su vez, afecta su rendimiento.

El tamaño de una solicitud de compilación puede tener una implicación significativa en el rendimiento de la compilación. Una compilación más grande podría representar más trabajo en el análisis y la construcción de los gráficos de compilación. El crecimiento orgánico de las compilaciones se produce naturalmente con el desarrollo, a medida que se agregan o crean más dependencias y, por lo tanto, crecen en complejidad y se vuelven más costosos de compilar.

Podemos dividir este problema en las distintas fases de compilación y usar las siguientes métricas como métricas de proxy para el trabajo realizado en cada fase:

PackageMetrics.packages_loaded: Es la cantidad de paquetes que se cargaron de forma correcta. Aquí, una regresión representa más trabajo que se debe realizar para leer y analizar cada archivo BUILD adicional en la fase de carga.
- A menudo, esto se debe a la adición de dependencias y a la necesidad de cargar su cierre transitivo.
- Usa query / cquery para encontrar dónde se pueden haber agregado dependencias nuevas.
TargetMetrics.targets_configured: Representa la cantidad de destinos y aspectos configurados en la compilación. Una regresión representa más trabajo en la construcción y el recorrido del grafo de destino configurado.
- A menudo, esto se debe a la adición de dependencias y a la necesidad de construir el gráfico de su cierre transitivo.
- Usa cquery para encontrar dónde se podrían haber agregado nuevas dependencias.
ActionSummary.actions_created: Representa las acciones creadas en la compilación, y una regresión representa más trabajo en la construcción del gráfico de acciones. Ten en cuenta que esto también incluye las acciones sin usar que podrían no haberse ejecutado.
- Usa aquery para depurar regresiones. Te sugerimos comenzar con --output=summary antes de desglosar aún más con --skyframe_state.
ActionSummary.actions_executed: Es la cantidad de acciones ejecutadas; una regresión representa directamente más trabajo en la ejecución de estas acciones.
- Las BEP escriben las estadísticas de acciones ActionData que muestran los tipos de acciones más ejecutadas. De forma predeterminada, se recopilan los 20 tipos de acciones principales, pero puedes pasar la --experimental_record_metrics_for_all_mnemonics para recopilar estos datos de todos los tipos de acciones que se ejecutaron.
- Esto debería ayudarte a determinar qué tipo de acciones se ejecutaron (además).
BuildGraphSummary.outputArtifactCount: Es la cantidad de artefactos creados por las acciones ejecutadas.
- Si la cantidad de acciones ejecutadas no aumentó, es probable que se haya cambiado la implementación de una regla.

Todas estas métricas se ven afectadas por el estado de la caché local, por lo que deberás asegurarte de que las compilaciones de las que extraigas estas métricas sean compilaciones limpias.

Notamos que una regresión en cualquiera de estas métricas puede estar acompañada de regresiones en el tiempo, el tiempo de CPU y el uso de memoria.

Uso de recursos locales

Bazel consume una variedad de recursos en tu máquina local (tanto para analizar el gráfico de compilación y controlar la ejecución como para ejecutar acciones locales), esto puede afectar el rendimiento o la disponibilidad de tu máquina cuando realiza la compilación, además de otras tareas.

Tiempo transcurrido

Quizás, las métricas más susceptibles al ruido (y pueden variar mucho de una compilación a otra) sean el tiempo, en particular, el tiempo real, de CPU y del sistema. Puedes usar bazel-bench para obtener comparativas de estas métricas y, con una cantidad suficiente de --runs, puedes aumentar la importancia estadística de tu medición.

El tiempo de pared es el tiempo real transcurrido.
- Si solo se regresa el tiempo, sugerimos recopilar un perfil de registro JSON y buscar diferencias. De lo contrario, es probable que sea más eficiente investigar otras métricas con regresión, ya que podrían haber afectado el tiempo.
El tiempo de CPU es el tiempo que dedica la CPU a ejecutar el código de usuario.
- Si el tiempo de CPU se revierte a través de dos confirmaciones de proyecto, sugerimos recopilar un perfil de CPU de Starlark. Es probable que también debas usar --nobuild para restringir la compilación a la fase de análisis, ya que allí es donde se realiza la mayor parte del trabajo pesado de la CPU.
El tiempo del sistema es el tiempo que la CPU ocupa en el kernel.
- Si la hora del sistema se regresa, se correlaciona principalmente con la E/S cuando Bazel lee archivos de tu sistema.

Creación de perfiles de carga de todo el sistema

Con la marca --experimental_collect_load_average_in_profiler que se introdujo en Bazel 6.0, el generador de perfiles de seguimiento de JSON recopila el promedio de carga del sistema durante la invocación.

Figura 1. Perfil que incluye el promedio de carga del sistema.

Una carga alta durante una invocación de Bazel puede ser un indicador de que Bazel programa demasiadas acciones locales en paralelo para tu máquina. Te recomendamos que ajustes --local_cpu_resources y --local_ram_resources, en especial en entornos de contenedores (al menos hasta que se combine #16512).

Supervisa el uso de memoria de Bazel

Hay dos fuentes principales para obtener el uso de memoria de Bazel: info de Bazel y la BEP.

bazel info used-heap-size-after-gc: Es la cantidad de memoria usada en bytes después de una llamada a System.gc().
- Bazel Bench también proporciona comparativas para esta métrica.
- Además, existen peak-heap-size, max-heap-size, used-heap-size y committed-heap-size (consulta la documentación), pero son menos relevantes.
MemoryMetrics.peak_post_gc_heap_size de BEP: Tamaño del tamaño máximo del montón de JVM en bytes posteriores a la recolección (requiere la configuración de --memory_profile que intenta forzar una GC completa).

Por lo general, una regresión en el uso de memoria es el resultado de una regresión en las métricas de tamaño de la solicitud de compilación, que a menudo se debe a la adición de dependencias o a un cambio en la implementación de la regla.

Para analizar el uso de memoria de Bazel en un nivel más detallado, te recomendamos que uses el generador de perfiles de memoria integrado para las reglas.

Generación de perfiles de memoria de trabajadores persistentes

Si bien los trabajadores persistentes pueden ayudar a acelerar las compilaciones de manera significativa (en especial para los lenguajes interpretados), su espacio en memoria puede ser problemático. Bazel recopila métricas sobre sus trabajadores; en particular, el campo WorkerMetrics.WorkerStats.worker_memory_in_kb indica cuánta memoria usan los trabajadores de memoria (por mnemotécnica).

El Generador de perfiles de seguimiento de JSON también recopila el uso de memoria persistente de los trabajadores durante la invocación mediante el paso de la marca --experimental_collect_system_network_usage (nueva en Bazel 6.0).

Figura 2: Perfil que incluye el uso de memoria de los trabajadores.

Reducir el valor de --worker_max_instances (valor predeterminado 4) podría ayudar a reducir la cantidad de memoria que usan los trabajadores persistentes. Estamos trabajando de forma activa para hacer que el administrador de recursos y el programador de Bazel sea más inteligente a fin de que ese ajuste se requiera con menos frecuencia en el futuro.

Supervisa el tráfico de red para compilaciones remotas

En la ejecución remota, Bazel descarga artefactos que se compilaron como resultado de la ejecución de acciones. Por lo tanto, el ancho de banda de tu red puede afectar el rendimiento de tu compilación.

Si usas la ejecución remota para tus compilaciones, te recomendamos que consideres supervisar el tráfico de red durante la invocación con el prototipo NetworkMetrics.SystemNetworkStats de BEP (es necesario pasar --experimental_collect_system_network_usage).

Además, los perfiles de registro de JSON te permiten ver el uso de red en todo el sistema durante la compilación cuando pasas la marca --experimental_collect_system_network_usage (nueva en Bazel 6.0).

Figura 3: Perfil que incluye el uso de la red en todo el sistema.

Un uso de red alto, pero bastante plano cuando se usa la ejecución remota, puede indicar que la red es el cuello de botella de tu compilación. Si aún no la usas, considera activar la compilación sin los bytes pasando --remote_download_minimal. Esto acelerará tus compilaciones, ya que evitará la descarga de artefactos intermedios innecesarios.

Otra opción es configurar una caché de disco local para ahorrar ancho de banda de descarga.