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 multiplex permiten que Bazel maneje múltiples solicitudes con un solo trabajador. el proceso de administración de recursos. 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 una de trabajador por trabajador, Bazel puede hacer que cuatro trabajadores multiplexados se comuniquen con el mismo proceso de trabajador, que luego puede controlar 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 algunas personas
mnemotécnicos que pueden ejecutar procesos en paralelo, Bazel obtiene un WorkerProxy de
el grupo de trabajadores. WorkerProxy reenvía las solicitudes al proceso trabajador
de forma secuencial junto con un request_id, el proceso trabajador procesa la solicitud
y envía respuestas a WorkerMultiplexer. Cuando el WorkerMultiplexer
recibe una respuesta, analiza el request_id y, luego, reenvía las respuestas
de vuelta al WorkerProxy correcto. 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 una sola cuenta
invocación, cada nombre mnemotécnico único solo puede tener un WorkerMultiplexer y un
proceso de trabajador. El número total de trabajadores, incluidos los trabajadores regulares y
WorkerProxy, sigue estando limitada por --worker_max_instances.
Cómo escribir reglas compatibles con multiplex
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 incluso
aunque puede haber varias solicitudes
acumulándose 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
request_id de la solicitud que está manejando.
Cómo manejar salidas multiplex
Los trabajadores multiplex deben ser más cuidadosos al manejar sus resultados que
trabajadores de un soloplex. 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. Al redireccionar stdout
en stderr es una buena idea, no recopiles ese resultado en output
de WorkResponse, ya que podría mostrar al usuario fragmentos de resultados alterados.
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.
Cómo habilitar trabajadores multiplex
Los trabajadores multiplex no están habilitados de forma predeterminada. Un conjunto de reglas puede activar el multiplex
trabajadores con la etiqueta supports-multiplex-workers en
execution_requirements de una acción (al igual que la etiqueta supports-workers)
habilita a los trabajadores normales). Como sucede con los trabajadores regulares,
la estrategia debe especificarse, 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
necesario, y supports-multiplex-workers tiene prioridad sobre
supports-workers, si se configuraron ambos. Puedes desactivar los trabajadores multiplex
de forma global pasando --noworker_multiplex.
Se recomienda usar un conjunto de reglas para usar trabajadores multiplex si es posible para reducir la memoria presión y mejorar el rendimiento. Sin embargo, en la actualidad, no se pueden usar compatible con la ejecución dinámica, a menos que implementar zonas de pruebas multiplex. 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 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 zonas de pruebas multiplex, el trabajador debe usar el campo sandbox_dir
de WorkRequest y úsalo 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
traduce las rutas de acceso a los archivos que se encuentran en arguments y inputs para leer de esto
ruta de acceso modificada y también debe escribir todos los resultados relacionados con sandbox_dir.
Esto incluye rutas como “.” y aquellas encontradas en archivos especificados
en los argumentos (como "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á zonas de pruebas multiplex
si se pasa la marca --experimental_worker_multiplex_sandboxing
el trabajador se usa con la 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 está
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