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