En esta página, se explica cómo usar trabajadores persistentes, los beneficios, los requisitos y la forma en que los trabajadores afectan la zona de pruebas.
Un trabajador persistente es un proceso de larga duración iniciado por el servidor de Bazel, que funciona como un wrapper alrededor de la tool real (por lo general, un compilador) o es la herramienta en sí. Para beneficiarse de los trabajadores persistentes, la herramienta debe admitir la realización de una secuencia de compilaciones, y el wrapper debe traducir entre la API de la herramienta y el formato de solicitud/respuesta que se describe a continuación. Se puede llamar al mismo trabajador con y sin la marca --persistent_worker en la misma compilación, y es responsable de iniciar y comunicarse con la herramienta de manera adecuada, además de cerrar a los trabajadores cuando sale. A cada instancia de trabajador se le asigna (pero no se le agrega un fragmento) un directorio de trabajo independiente en <outputBase>/bazel-workers.
El uso de trabajadores persistentes es una estrategia de ejecución que disminuye la sobrecarga de inicio, permite una mayor compilación JIT y habilita el almacenamiento en caché de, por ejemplo, los árboles de sintaxis abstractos en la ejecución de la acción. Para lograr estas mejoras, esta estrategia envía varias solicitudes a un proceso de larga duración.
Los trabajadores persistentes se implementan en varios lenguajes, incluidos Java, Scala y Kotlin, entre otros.
Los programas que usan un entorno de ejecución NodeJS pueden usar la biblioteca auxiliar @bazel/worker para implementar el protocolo de trabajador.
Usa trabajadores persistentes
Bazel 0.27 y versiones posteriores
usa trabajadores persistentes de forma predeterminada cuando ejecutan compilaciones, aunque la ejecución
remota tiene prioridad. En el caso de las acciones que no admiten trabajadores persistentes,
Bazel recurre a iniciar una instancia de herramienta para cada acción. Puedes configurar explícitamente tu compilación para que use trabajadores persistentes si estableces la estrategia worker para los mnemotécnicos de la herramienta aplicables. Como práctica recomendada, en este ejemplo se incluye especificar local como resguardo de la estrategia worker:
bazel build //my:target --strategy=Javac=worker,local
Usar la estrategia de trabajadores en lugar de la estrategia local puede aumentar la velocidad de compilación de forma significativa, según la implementación. En el caso de Java, las compilaciones pueden ser entre 2 y 4 veces más rápidas; a veces, más para la compilación incremental. La compilación de Bazel es 2.5 veces más rápida con los trabajadores. Para obtener más detalles, consulta la sección “Elige la cantidad de trabajadores”.
Si también tienes un entorno de compilación remoto que coincide con el entorno de compilación
local, puedes usar la estrategia dinámica experimental,
que ejecuta una ejecución remota y una de trabajador. Para habilitar la estrategia dinámica, pasa la marca --experimental_spawn_scheduler. Esta estrategia habilita automáticamente a los trabajadores, por lo que no es necesario especificar la estrategia worker, pero puedes usar local o sandboxed como resguardos.
Elige la cantidad de trabajadores
La cantidad predeterminada de instancias de trabajadores por mnemotécnica es 4, pero se puede ajustar con la marca worker_max_instances. Hay una compensación entre hacer un buen uso de las CPU disponibles y la cantidad de compilación JIT y aciertos de caché que obtienes. Con más trabajadores, más
objetivos pagarán los costos de inicio que implica ejecutar código que no sea JIT y almacenar en cachés
inferidas. Si tienes que compilar una pequeña cantidad de destinos, es posible que un solo trabajador ofrezca el mejor equilibrio entre la velocidad de compilación y el uso de recursos (por ejemplo, consulta el error #8586).
La marca worker_max_instances establece la cantidad máxima de instancias de trabajadores por mnemotecnia y conjunto de marcas (consulta a continuación), por lo que, en un sistema mixto, podrías terminar usando mucha memoria si mantienes el valor predeterminado. Para las compilaciones incrementales, el beneficio de varias instancias de trabajador es aún menor.
En este gráfico, se muestran los tiempos de compilación desde cero de Bazel (objetivo //src:bazel) en una estación de trabajo Intel Xeon de 6 núcleos hipersubproceso con Linux de 3.5 GHz y 64 GB de RAM. Para cada configuración de trabajadores, se ejecutan cinco compilaciones limpias y se toma el promedio de las últimas cuatro.
Figura 1. Gráfico de mejoras en el rendimiento de compilaciones limpias.
Para esta configuración, dos trabajadores proporcionan la compilación más rápida, aunque con solo una mejora del 14% en comparación con un trabajador. Un trabajador es una buena opción si deseas usar menos memoria.
Por lo general, la compilación incremental ofrece beneficios aún más altos. Las compilaciones limpias son relativamente raras, pero cambiar un solo archivo entre compilaciones es común, en particular, en el desarrollo basado en pruebas. El ejemplo anterior también tiene algunas acciones de empaquetado que no son de Java que pueden oscurecer el tiempo de compilación incremental.
Volver a compilar las fuentes de Java solo (//src/main/java/com/google/devtools/build/lib/bazel:BazelServer_deploy.jar) después de cambiar una constante de cadena interna en AbstractContainerizingSandboxedSpawn.java permite una aceleración del triple (en promedio, 20 compilaciones incrementales con una compilación de preparación descartada):
Figura 2: Gráfico de mejoras de rendimiento de compilaciones incrementales.
La aceleración depende del cambio que se realice. La aceleración de un factor 6 se mide en la situación anterior, cuando se cambia una constante de uso general.
Modifica a los trabajadores persistentes
Puedes pasar la marca --worker_extra_flag para especificar las marcas de inicio a los trabajadores, con clave mnemotécnica. Por ejemplo, si pasas --worker_extra_flag=javac=--debug, se activa la depuración solo para Javac.
Solo se puede configurar una marca de trabajador por uso de esta marca y solo para un valor mnemotécnico.
Los trabajadores no solo se crean por separado para cada uso mnemotécnico, sino también para las variaciones de sus marcas de inicio. Cada combinación de marcas mnemotécnicas y de inicio se combina en un WorkerKey y, para cada WorkerKey, se pueden crear hasta worker_max_instances trabajadores. Consulta la siguiente sección para conocer cómo la configuración de la acción también puede especificar marcas de configuración.
Puedes usar la marca --high_priority_workers para especificar un valor mnemotécnico que se debe ejecutar antes que los mnemotécnicos de prioridad normal. Esto puede ayudar a priorizar acciones que siempre están en la ruta crítica. Si hay dos o más trabajadores de prioridad alta que ejecutan solicitudes, los demás trabajadores no pueden ejecutarse. Esta marca se puede usar varias veces.
Pasar la marca --worker_sandboxing hace que cada solicitud de trabajador use un directorio de zona de pruebas independiente para todas sus entradas. La configuración de la sandbox lleva tiempo adicional, especialmente en macOS, pero brinda una mejor garantía de precisión.
La marca --worker_quit_after_build es útil principalmente para depurar y generar perfiles. Esta marca obliga a todos los trabajadores
a cerrar una vez que se completa una compilación. También puedes pasar --worker_verbose para obtener más resultados sobre lo que hacen los trabajadores. Esta marca se refleja en el campo verbosity de WorkRequest, lo que permite que las implementaciones de trabajadores también sean más detalladas.
Los trabajadores almacenan sus registros en el directorio <outputBase>/bazel-workers, por ejemplo, /tmp/_bazel_larsrc/191013354bebe14fdddae77f2679c3ef/bazel-workers/worker-1-Javac.log.
El nombre del archivo incluye el ID del trabajador y el nombre nemotécnico. Dado que puede haber más de un WorkerKey por mnemotécnica, es posible que veas más de worker_max_instances archivos de registro para un valor mnemotécnico determinado.
Para compilaciones de Android, consulta los detalles en la página de rendimiento de compilación de Android.
Implementa trabajadores persistentes
Consulta la página Crea trabajadores persistentes para obtener más información sobre cómo crear un trabajador.
En este ejemplo, se muestra una configuración de Starlark para un trabajador que usa JSON:
args_file = ctx.actions.declare_file(ctx.label.name + "_args_file")
ctx.actions.write(
output = args_file,
content = "\n".join(["-g", "-source", "1.5"] + ctx.files.srcs),
)
ctx.actions.run(
mnemonic = "SomeCompiler",
executable = "bin/some_compiler_wrapper",
inputs = inputs,
outputs = outputs,
arguments = [ "-max_mem=4G", "@%s" % args_file.path],
execution_requirements = {
"supports-workers" : "1", "requires-worker-protocol" : "json" }
)
Con esta definición, el primer uso de esta acción comenzaría con la ejecución de la línea de comandos /bin/some_compiler -max_mem=4G --persistent_worker. Una solicitud para compilar Foo.java debería verse de la siguiente manera:
NOTA: Si bien la especificación del búfer de protocolo usa "mayúsculas y minúsculas" (request_id), el protocolo JSON usa "mayúsculas mediales" (requestId). En este documento, usaremos mayúsculas mediales en los ejemplos de JSON, pero usaremos mayúsculas mediales cuando hablemos sobre el campo, independientemente del protocolo.
{
"arguments": [ "-g", "-source", "1.5", "Foo.java" ]
"inputs": [
{ "path": "symlinkfarm/input1", "digest": "d49a..." },
{ "path": "symlinkfarm/input2", "digest": "093d..." },
],
}
El trabajador recibe esto en stdin en formato JSON delimitado por saltos de línea (porque requires-worker-protocol está configurado como JSON). Luego, el trabajador realiza la acción y envía un WorkResponse con formato JSON a Bazel en su stdout. Luego, Bazel
analiza esta respuesta y la convierte de forma manual en un archivo proto WorkResponse. Para comunicarse con el trabajador asociado mediante protobuf con codificación binaria en lugar de JSON, requires-worker-protocol se establece en proto de la siguiente manera:
execution_requirements = {
"supports-workers" : "1" ,
"requires-worker-protocol" : "proto"
}
Si no incluyes requires-worker-protocol en los requisitos de ejecución, Bazel usará la comunicación de trabajador de forma predeterminada para usar protobuf.
Bazel obtiene el WorkerKey de las marcas mnemotécnicas y compartidas, por lo que, si esta
configuración permitiera cambiar el parámetro max_mem, se generará un trabajador independiente
para cada valor usado. lo que puede generar un consumo excesivo de memoria si se usan demasiadas variaciones.
Actualmente, cada trabajador solo puede procesar una solicitud a la vez. La función experimental de trabajadores multiplex permite usar varios subprocesos si la herramienta subyacente tiene varios subprocesos y el wrapper está configurado para comprender esto.
En este repositorio de GitHub, puedes ver ejemplos de wrappers de trabajador escritos en Java y en Python. Si trabajas en JavaScript o TypeScript, el paquete@bazel/worker y el ejemplo de trabajador nodejs pueden ser útiles.
¿Cómo afectan los trabajadores a la zona de pruebas?
El uso de la estrategia worker de forma predeterminada no ejecuta la acción en una
sandbox, similar a la estrategia local. Puedes configurar la
marca --worker_sandboxing para que ejecute todos los trabajadores dentro de las zonas de pruebas y asegurarte de que
cada ejecución de la herramienta solo vea los archivos de entrada que debe tener. Es posible que la herramienta aún filtre información entre solicitudes internas, por ejemplo, a través de una caché. El uso de la estrategia dynamic requiere que los trabajadores estén en una zona de pruebas.
Para permitir el uso correcto de las cachés del compilador con los trabajadores, se pasa un resumen junto con cada archivo de entrada. Por lo tanto, el compilador o el wrapper pueden verificar si la entrada aún es válida sin tener que leer el archivo.
Incluso cuando se usan los resúmenes de entrada para protegerse contra el almacenamiento en caché no deseado, los trabajadores de la zona de pruebas ofrecen una zona de pruebas menos estricta que una zona de pruebas pura, ya que la herramienta puede mantener otro estado interno afectado por solicitudes anteriores.
Los trabajadores multiplex solo se pueden usar en la zona de pruebas si la implementación de trabajadores lo admite.
Además, esta zona de pruebas debe habilitarse por separado con la marca
--experimental_worker_multiplex_sandboxing. Obtén más detalles en el documento de diseño.
Lecturas adicionales
Para obtener más información sobre los trabajadores persistentes, consulta:
- Entrada de blog original sobre los trabajadores persistentes
- Descripción de la implementación de Haskell {: .external}
- Entrada de blog de Mike Morearty {: .external}
- Desarrollo de frontend con Bazel: Angular/TypeScript y trabajadores persistentes con Asana {: .external}
- Explicación de las estrategias de Bazel {: .external}
- Debate sobre la estrategia informativa de los trabajadores en la lista de distribución de bazel-discuss {: .external}