En esta página, se describen los trabajadores multiplex, cómo escribir compatibilidad con multiplex reglas de firewall y soluciones alternativas para ciertas limitaciones.
Los trabajadores multiplexados permiten que Bazel controle varias solicitudes con un solo proceso de trabajador. En el caso de los trabajadores que realizan varios subprocesos, Bazel puede usar menos recursos para lograr el mismo rendimiento o uno mejor. Por ejemplo, en lugar de tener un proceso de trabajador por trabajador, Bazel puede tener cuatro trabajadores multiplexados que se comunican con el mismo proceso de trabajador, que luego puede controlar las solicitudes en paralelo. Para lenguajes como Java y Scala, lo que ahorra tiempo de preparación de JVM y compilación de JIT tiempo y, en general, permite usar una caché compartida entre todos los trabajadores de del mismo tipo.
Descripción general
Existen dos capas entre el servidor de Bazel y el proceso del trabajador. Para ciertas mnemotecnias que pueden ejecutar procesos en paralelo, Bazel obtiene un WorkerProxy del grupo de trabajadores. WorkerProxy reenvía las solicitudes al proceso de trabajo de forma secuencial junto con un request_id. El proceso de trabajo procesa la solicitud y envía respuestas a WorkerMultiplexer. Cuando WorkerMultiplexer recibe una respuesta, analiza request_id y, luego, reenvía las respuestas a la WorkerProxy correcta. Al igual que con los trabajadores no multiplexados,
la comunicación se hace a través de entrada/salida estándar, pero la herramienta no puede utilizar
stderr para el resultado visible para el usuario (consulta a continuación).
Cada trabajador tiene una clave. Bazel usa el código hash de la clave (compuesto por el entorno
variables, la raíz de ejecución y el nombre nemotécnico) para determinar qué
WorkerMultiplexer para usar. Los elementos WorkerProxy se comunican con la misma
WorkerMultiplexer si tienen el mismo código hash Por lo tanto, si asumimos
las variables de entorno y la raíz de ejecución son las mismas en un único módulo
invocación, cada nombre mnemotécnico único solo puede tener un WorkerMultiplexer y un
proceso de trabajador. La cantidad total de trabajadores, incluidos los trabajadores habituales y los WorkerProxy, sigue limitada por --worker_max_instances.
Cómo escribir reglas compatibles con multiplexación
El proceso de trabajador de la regla
debe ser de varios subprocesos para aprovechar
trabajadores multiplex. Protobuf permite que un conjunto de reglas analice una sola solicitud, aunque haya varias solicitudes apiladas en el flujo. Siempre que el
de trabajo analiza una solicitud desde la transmisión, debe controlarla
una conversación nueva. Debido a que un subproceso diferente podría completarse y escribir en la transmisión en
al mismo tiempo, el proceso del trabajador debe asegurarse de que las respuestas estén escritas
de forma atómica (los mensajes no se superponen). Las respuestas deben contener el request_id de la solicitud que controlan.
Cómo controlar la salida de multiplexación
Los trabajadores de multiplexación deben tener más cuidado con el manejo de su producción que los trabajadores de monoplexación. Todo lo que se envíe a stderr se incluirá en un único archivo de registro
compartidos entre todos los WorkerProxy del mismo tipo,
intercalados al azar entre solicitudes simultáneas. Si bien es una buena idea redireccionar stdout a stderr, no recopiles ese resultado en el campo output de WorkResponse, ya que podría mostrarle al usuario fragmentos de salida dañados.
Si tu herramienta solo envía resultados orientados al usuario a stdout o stderr, deberás hacer lo siguiente:
es necesario cambiar ese comportamiento
antes de habilitar los trabajadores multiplex.
Habilitación de trabajadores multiplex
Los trabajadores multiplex no están habilitados de forma predeterminada. Un conjunto de reglas puede activar trabajadores de multiplexación con la etiqueta supports-multiplex-workers en el execution_requirements de una acción (al igual que la etiqueta supports-workers habilita a los trabajadores normales). Al igual que cuando se usan trabajadores normales, se debe especificar una estrategia de trabajador, ya sea a nivel del conjunto de reglas (por ejemplo, --strategy=[some_mnemonic]=worker) o, en general, a nivel de la estrategia (por ejemplo, --dynamic_local_strategy=worker,standalone). No se necesitan marcas adicionales, y supports-multiplex-workers tiene prioridad sobre supports-workers si se configuran ambos. Puedes desactivar los trabajadores de multiplexación de forma global pasando --noworker_multiplex.
Se recomienda que un conjunto de reglas use trabajadores multiplexores si es posible para reducir la presión de la memoria y mejorar el rendimiento. Sin embargo, por el momento, los trabajadores de multiplexación no son compatibles con la ejecución dinámica, a menos que implementen la zona de pruebas de multiplexación. Intentando ejecutar multiplex sin zona de pruebas los trabajadores con ejecución dinámica usarán silenciosamente trabajadores singleplex en su lugar.
Zona de pruebas de multiplex
Los trabajadores multiplex se pueden implementar en la zona de pruebas agregando compatibilidad explícita para ellos en el implementaciones de trabajadores. Si bien la zona de pruebas de trabajadores de un soloplex puede realizarse mediante los trabajadores multiplex comparten la procesar un directorio de trabajo entre varias solicitudes paralelas. Para permitir zona de pruebas de trabajadores multiplex, el trabajador debe admitir la lectura y escribiendo en un subdirectorio especificado en cada solicitud, en vez de directamente su directorio de trabajo.
Para admitir la zona de pruebas multiplexada, el trabajador debe usar el campo sandbox_dir de WorkRequest y usarlo como prefijo para todas las operaciones de lectura y escritura de archivos.
Mientras que los campos arguments y inputs permanecen sin cambios desde una zona de pruebas no incluida en la zona de pruebas
las entradas reales están relacionadas con el sandbox_dir. El trabajador debe traducir las rutas de acceso a los archivos que se encuentran en arguments y inputs para leer desde esta ruta de acceso modificada y también debe escribir todas las salidas en relación con sandbox_dir.
Esto incluye rutas como ".", así como las rutas que se encuentran en los archivos especificados
en los argumentos (como los argumentos "argfile").
Una vez que un trabajador admite la zona de pruebas multiplex, el conjunto de reglas puede declararlo
si agregas supports-multiplex-sandboxing al elemento
execution_requirements de una acción. Luego, Bazel usará la zona de pruebas múltiple
si se pasa la marca --experimental_worker_multiplex_sandboxing o si
se usa el trabajador con ejecución dinámica.
Los archivos de trabajador de un trabajador multiplex de zona de pruebas siguen siendo relativos al
directorio de trabajo del proceso trabajador. Por lo tanto, si un archivo es
usarse para ejecutar el trabajador y como entrada, debe especificarse como
una entrada en el argumento del archivo de marcas y en tools, executable o
runfiles