Trang này mô tả về trình thực thi multiplex, cách viết các quy tắc tương thích với multiplex và giải pháp cho một số hạn chế nhất định.
Trình thực thi multiplex cho phép Bazel xử lý nhiều yêu cầu bằng một quy trình thực thi. Đối với trình thực thi đa luồng, Bazel có thể sử dụng ít tài nguyên hơn để đạt được hiệu suất tương đương hoặc tốt hơn. Ví dụ: thay vì có một quy trình thực thi cho mỗi trình thực thi, Bazel có thể có 4 trình thực thi multiplex giao tiếp với cùng một quy trình thực thi, sau đó có thể xử lý các yêu cầu song song. Đối với các ngôn ngữ như Java và Scala, điều này giúp tiết kiệm thời gian khởi động JVM và thời gian biên dịch JIT, đồng thời cho phép sử dụng một bộ nhớ đệm dùng chung giữa tất cả các trình thực thi cùng loại.
Tổng quan
Có 2 lớp giữa máy chủ Bazel và quy trình thực thi. Đối với một số từ gợi nhớ có thể chạy các quy trình song song, Bazel sẽ nhận được WorkerProxy từ nhóm trình thực thi. WorkerProxy chuyển tiếp các yêu cầu đến quy trình thực thi theo tuần tự cùng với request_id, quy trình thực thi sẽ xử lý yêu cầu và gửi phản hồi đến WorkerMultiplexer. Khi WorkerMultiplexer nhận được phản hồi, nó sẽ phân tích cú pháp request_id, sau đó chuyển tiếp các phản hồi trở lại WorkerProxy chính xác. Giống như với các trình thực thi không multiplex, tất cả
hoạt động giao tiếp đều được thực hiện qua đầu vào/đầu ra tiêu chuẩn, nhưng công cụ này không thể chỉ sử dụng
stderr cho đầu ra mà người dùng nhìn thấy (xem bên dưới).
Mỗi trình thực thi đều có một khoá. Bazel sử dụng mã băm của khoá (bao gồm các biến môi trường, thư mục gốc thực thi và từ gợi nhớ) để xác định WorkerMultiplexer cần sử dụng. WorkerProxy giao tiếp với cùng một WorkerMultiplexer nếu chúng có cùng mã băm. Do đó, giả sử các biến môi trường và thư mục gốc thực thi giống nhau trong một lệnh gọi Bazel, thì mỗi từ gợi nhớ duy nhất chỉ có thể có một WorkerMultiplexer và một quy trình thực thi. Tổng số trình thực thi, bao gồm cả trình thực thi thông thường và WorkerProxy, vẫn bị giới hạn bởi --worker_max_instances.
Viết các quy tắc tương thích với multiplex
Quy trình thực thi của quy tắc phải là đa luồng để tận dụng trình thực thi multiplex. Protobuf cho phép một bộ quy tắc phân tích cú pháp một yêu cầu duy nhất ngay cả khi có nhiều yêu cầu đang xếp chồng lên nhau trong luồng. Bất cứ khi nào quy trình thực thi phân tích cú pháp một yêu cầu từ luồng, quy trình này sẽ xử lý yêu cầu trong một luồng mới. Vì các luồng khác nhau có thể hoàn thành và ghi vào luồng cùng một lúc, nên quy trình thực thi cần đảm bảo rằng các phản hồi được ghi một cách nguyên tử (các thông báo không chồng chéo). Các phản hồi phải chứa request_id của yêu cầu mà chúng đang xử lý.
Xử lý đầu ra multiplex
Trình thực thi multiplex cần cẩn thận hơn về việc xử lý đầu ra so với trình thực thi singleplex. Mọi nội dung được gửi đến stderr sẽ chuyển vào một tệp nhật ký duy nhất được chia sẻ giữa tất cả WorkerProxy cùng loại, được xen kẽ ngẫu nhiên giữa các yêu cầu đồng thời. Mặc dù việc chuyển hướng stdout vào stderr là một ý tưởng hay, nhưng đừng thu thập đầu ra đó vào trường output của WorkResponse, vì điều đó có thể cho người dùng thấy các phần đầu ra bị hỏng.
Nếu công cụ của bạn chỉ gửi đầu ra hướng đến người dùng đến stdout hoặc stderr, bạn sẽ cần thay đổi hành vi đó trước khi có thể bật trình thực thi multiplex.
Bật trình thực thi multiplex
Trình thực thi multiplex không được bật theo mặc định. Một bộ quy tắc có thể bật trình thực thi multiplex bằng cách sử dụng thẻ supports-multiplex-workers trong execution_requirements của một hành động (giống như thẻ supports-workers bật trình thực thi thông thường). Như trường hợp sử dụng trình thực thi thông thường, bạn cần chỉ định một chiến lược trình thực thi, ở cấp bộ quy tắc (ví dụ: --strategy=[some_mnemonic]=worker) hoặc thường ở cấp chiến lược (ví dụ: --dynamic_local_strategy=worker,standalone). Không cần thêm cờ và supports-multiplex-workers sẽ được ưu tiên hơn supports-workers nếu cả hai đều được đặt. Bạn có thể tắt trình thực thi multiplex trên toàn cục bằng cách truyền --noworker_multiplex.
Bạn nên sử dụng trình thực thi multiplex nếu có thể, để giảm áp lực bộ nhớ và cải thiện hiệu suất. Tuy nhiên, trình thực thi multiplex hiện không tương thích với quá trình thực thi động trừ phi chúng triển khai hộp cát multiplex. Việc cố gắng chạy trình thực thi multiplex không chạy trong môi trường hộp cát với quá trình thực thi động sẽ tự động sử dụng trình thực thi singleplex chạy trong môi trường hộp cát.
Hộp cát multiplex
Bạn có thể chạy trình thực thi multiplex trong môi trường hộp cát bằng cách thêm tính năng hỗ trợ rõ ràng cho trình thực thi này trong quá trình triển khai trình thực thi. Mặc dù bạn có thể chạy trình thực thi singleplex trong môi trường hộp cát bằng cách chạy từng quy trình thực thi trong hộp cát riêng, nhưng trình thực thi multiplex sẽ chia sẻ thư mục làm việc của quy trình giữa nhiều yêu cầu song song. Để cho phép chạy trình thực thi multiplex trong môi trường hộp cát, trình thực thi phải hỗ trợ việc đọc và ghi vào một thư mục con được chỉ định trong mỗi yêu cầu, thay vì trực tiếp trong thư mục làm việc của trình thực thi.
Để hỗ trợ hộp cát multiplex, trình thực thi phải sử dụng trường sandbox_dir từ WorkRequest và sử dụng trường đó làm tiền tố cho tất cả hoạt động đọc và ghi tệp.
Mặc dù các trường arguments và inputs vẫn không thay đổi so với yêu cầu không chạy trong môi trường hộp cát, nhưng các đầu vào thực tế tương ứng với sandbox_dir. Trình thực thi phải dịch các đường dẫn tệp có trong arguments và inputs để đọc từ đường dẫn đã sửa đổi này, đồng thời phải ghi tất cả đầu ra tương ứng với sandbox_dir.
Điều này bao gồm các đường dẫn như '.', cũng như các đường dẫn có trong các tệp được chỉ định
trong đối số (chẳng hạn như "argfile" đối số).
Sau khi trình thực thi hỗ trợ hộp cát multiplex, bộ quy tắc có thể khai báo tính năng hỗ trợ này bằng cách thêm supports-multiplex-sandboxing vào execution_requirements của một hành động. Sau đó, Bazel sẽ sử dụng hộp cát multiplex nếu cờ --experimental_worker_multiplex_sandboxing được truyền hoặc nếu trình thực thi được sử dụng với quá trình thực thi động.
Các tệp trình thực thi của trình thực thi multiplex chạy trong môi trường hộp cát vẫn tương ứng với thư mục làm việc của quy trình thực thi. Do đó, nếu một tệp được dùng để chạy trình thực thi và làm đầu vào, thì tệp đó phải được chỉ định vừa là đầu vào trong đối số flagfile vừa trong tools, executable hoặc runfiles.