Trang này mô tả trình thực thi multiplex, cách viết các quy tắc tương thích với multiplex và các giải pháp thay thế 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 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 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 trình thực thi. Sau đó, quy trình này 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 trình thực thi. Đối với một số từ viết tắt có thể chạy các quy trình song song, Bazel sẽ nhận được một WorkerProxy từ nhóm trình thực thi. WorkerProxy chuyển tiếp các yêu cầu đến quy trình trình thực thi theo trình tự cùng với request_id. Quy trình trình thực thi 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 phản hồi trở lại WorkerProxy chính xác. Giống như 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 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ừ viết tắt) để 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ừ viết tắt duy nhất chỉ có thể có một WorkerMultiplexer và một quy trình 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 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 tích tụ trong luồng. Bất cứ khi nào quy trình 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 tất và ghi vào luồng cùng một lúc, nên quy trình 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). 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ẽ được đưa 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ể hiển thị cho người dùng 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ầu 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 tính năng chạy trong môi trường 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.
Chạy trong môi trường 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 tính năng này trong quá trình triển khai trình thực thi. Mặc dù bạn có thể chạy trong môi trường hộp cát trình thực thi singleplex bằng cách chạy từng quy trình trình thực thi trong môi trường hộp cát riêng, nhưng trình thực thi multiplex 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 trong môi trường hộp cát trình thực thi multiplex, 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ợ chạy trong môi trường 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ả cá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 tìm thấy 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 tìm thấy trong các tệp được chỉ định
trong các đối số (chẳng hạn như "argfile" đối số).
Sau khi trình thực thi hỗ trợ chạy trong môi trường 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 tính năng chạy trong môi trườ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 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.