En esta página, se describen los trabajadores de multiplexación, cómo escribir reglas compatibles con la multiplexación y las soluciones para ciertas limitaciones.
Los trabajadores multiplexados permiten que Bazel controle varias solicitudes con un solo proceso de trabajador. En el caso de los trabajadores con 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, esto ahorra tiempo de preparación de JVM y tiempo de compilación de JIT, y, en general, permite usar una caché compartida entre todos los trabajadores del mismo tipo.
Descripción general
Hay dos capas entre el servidor de Bazel y el proceso de trabajo. 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, toda la comunicación se realiza a través de entradas y salidas estándar, pero la herramienta no puede usar solo stderr para la salida visible para el usuario (consulta a continuación).
Cada trabajador tiene una clave. Bazel usa el código hash de la clave (compuesto por variables de entorno, la raíz de ejecución y el mnemónico) para determinar qué WorkerMultiplexer usar. Los WorkerProxy se comunican con el mismo WorkerMultiplexer si tienen el mismo código hash. Por lo tanto, si se supone que las variables de entorno y la raíz de ejecución son las mismas en una sola invocación de Bazel, cada mnemónica única solo puede tener un WorkerMultiplexer y un proceso de trabajador. La cantidad total de trabajadores, incluidos los trabajadores habituales y los WorkerProxy, aún está limitada por --worker_max_instances.
Cómo escribir reglas compatibles con multiplexación
El proceso de trabajo de la regla debe ser multiproceso para aprovechar los trabajadores multiplexados. Protobuf permite que un conjunto de reglas analice una sola solicitud, aunque haya varias solicitudes apiladas en el flujo. Cada vez que el proceso de trabajador analiza una solicitud de la transmisión, debe controlarla en un subproceso nuevo. Debido a que diferentes subprocesos pueden completarse y escribir en el flujo al mismo tiempo, el proceso de trabajo debe asegurarse de que las respuestas se escriban 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 irá a un solo archivo de registro que se compartirá entre todos los WorkerProxy del mismo tipo, intercalado de forma aleatoria 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 cambiar ese comportamiento antes de habilitar los trabajadores de multiplexación.
Habilitación de trabajadores multiplex
Los trabajadores de multiplexación no están habilitados de forma predeterminada. Un conjunto de reglas puede activar trabajadores multiplexados 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. Si intentas ejecutar trabajadores de multiplexación que no están en la zona de pruebas con ejecución dinámica, se usarán en silencio trabajadores de monoplexación que sí están en la zona de pruebas.
Zona de pruebas de multiplex
Para poner en la zona de pruebas los trabajadores de multiplexación, agrega compatibilidad explícita en las implementaciones de trabajadores. Si bien se puede ejecutar cada proceso de trabajador en su propia zona de pruebas para trabajadores de un solo plex, los trabajadores de multiplexación comparten el directorio de trabajo del proceso entre varias solicitudes en paralelo. Para permitir la zona de pruebas de trabajadores multiplexados, el trabajador debe admitir la lectura y escritura en un subdirectorio especificado en cada solicitud, en lugar de hacerlo directamente en 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.
Si bien los campos arguments y inputs no cambian desde una solicitud sin zona de pruebas, las entradas reales son relativas a 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 admita la zona de pruebas múltiple, el conjunto de reglas puede declarar esta compatibilidad agregando supports-multiplex-sandboxing al execution_requirements de una acción. Luego, Bazel usará la zona de pruebas multiplexada
si se pasa la marca --experimental_worker_multiplex_sandboxing o si
se usa el trabajador con ejecución dinámica.
Los archivos del trabajador de un trabajador de multiplexación en zona de pruebas siguen siendo relativos al directorio de trabajo del proceso de trabajador. Por lo tanto, si un archivo se usa para ejecutar el trabajador y como entrada, se debe especificar como entrada en el argumento del archivo de marcas y en tools, executable o runfiles.