หน้านี้อธิบายเกี่ยวกับผู้ปฏิบัติงาน Multiplex, วิธีเขียนกฎที่เข้ากันได้กับ Multiplex และวิธีแก้ปัญหาเบื้องต้นสำหรับข้อจำกัดบางอย่าง
ผู้ปฏิบัติงาน Multiplex ช่วยให้ Bazel จัดการคำขอหลายรายการด้วยกระบวนการสำหรับผู้ปฏิบัติงานเพียงกระบวนการเดียว สำหรับผู้ปฏิบัติงานแบบหลายเทรด Bazel สามารถใช้ทรัพยากรน้อยลงเพื่อให้ได้ประสิทธิภาพเท่าเดิมหรือดีขึ้น เช่น แทนที่จะมีผู้ปฏิบัติงาน 1 ขั้นตอนต่อคน Bazel สามารถให้ผู้ปฏิบัติงานมัลติเพล็กซ์ 4 คนพูดคุยกระบวนการเดียวกันสำหรับผู้ปฏิบัติงาน ซึ่งจะจัดการคำขอไปพร้อมกันได้ สำหรับภาษาต่างๆ เช่น Java และ Scala การดำเนินการนี้จะช่วยประหยัดเวลาในการอุ่นเครื่องของ JVM และเวลาการคอมไพล์ JIT และโดยทั่วไปแล้วจะใช้แคชที่ใช้ร่วมกันรายการเดียวระหว่างผู้ปฏิบัติงานทั้งหมดในประเภทเดียวกันได้
ภาพรวม
ระหว่างเซิร์ฟเวอร์ Bazel และกระบวนการทำงานของผู้ปฏิบัติงานจะมี 2 เลเยอร์ สำหรับความทรงจำบางอย่างที่เรียกใช้กระบวนการพร้อมกันได้ Bazel จะได้รับ WorkerProxy จากพูลผู้ปฏิบัติงาน WorkerProxy จะส่งต่อคำขอไปยังผู้ปฏิบัติงานตามลำดับพร้อมกับ request_id จากนั้นผู้ปฏิบัติงานจะดำเนินการตามคำขอและส่งการตอบกลับไปยัง WorkerMultiplexer เมื่อ WorkerMultiplexer ได้รับการตอบกลับ ก็จะแยกวิเคราะห์ request_id แล้วส่งต่อคำตอบกลับไปยัง WorkerProxy ที่ถูกต้อง เช่นเดียวกับผู้ปฏิบัติงานที่ไม่ใช่มัลติเพล็กซ์ การสื่อสารทั้งหมดจะดำเนินการผ่านเข้า/ออกแบบมาตรฐาน แต่เครื่องมือจะใช้เพียง stderr สำหรับเอาต์พุตที่ผู้ใช้มองเห็นไม่ได้ (ดูด้านล่าง)
โดยผู้ปฏิบัติงานแต่ละคนจะมีคีย์ Bazel ใช้โค้ดแฮชของคีย์ (ประกอบด้วยตัวแปรสภาพแวดล้อม รูทการดำเนินการ และข้อความช่วยจำ) ในการระบุ WorkerMultiplexer ที่จะใช้ โดย WorkerProxy จะสื่อสารกับ WorkerMultiplexer เดียวกันหากมีโค้ดแฮชเดียวกัน ดังนั้น สมมติว่าตัวแปรสภาพแวดล้อมและรูทการดำเนินการเหมือนกันในการเรียกใช้ Bazel ครั้งเดียว การช่วยจำที่ไม่ซ้ำกันแต่ละรายการจะมี WorkerMultiplexer และกระบวนการของผู้ปฏิบัติงานเพียงรายการเดียวเท่านั้น จำนวนผู้ปฏิบัติงานทั้งหมด ซึ่งรวมถึงผู้ปฏิบัติงานปกติและ WorkerProxy ยังคงถูกจำกัดอยู่ที่ --worker_max_instances
การเขียนกฎที่ใช้ได้กับ Multiplex
กระบวนการสำหรับผู้ปฏิบัติงานของกฎควรเป็นแบบมัลติเทรดเพื่อใช้ประโยชน์จากผู้ปฏิบัติงาน Multiplex Protobuf ช่วยให้ชุดกฎแยกวิเคราะห์คำขอเดียวได้ แม้ว่าอาจมีคำขอหลายรายการที่สะสมอยู่ในสตรีมก็ตาม เมื่อใดก็ตามที่กระบวนการของผู้ปฏิบัติงานแยกวิเคราะห์คำขอจากสตรีม กระบวนการดังกล่าวควรจัดการกับคำขอในเทรดใหม่ เนื่องจากเทรดที่ต่างกันอาจทำงานเสร็จสมบูรณ์และเขียนไปยังสตรีมได้ในเวลาเดียวกัน กระบวนการของผู้ปฏิบัติงานต้องตรวจสอบว่าคำตอบเหล่านั้นเขียนขึ้นอย่างถูกต้อง (ข้อความไม่ซ้อนทับกัน) การตอบกลับต้องมี request_id ของคำขอที่ตอบกลับอยู่
การจัดการเอาต์พุต Multiplex
ผู้ปฏิบัติงาน Multiplex ต้องระมัดระวังในการจัดการผลลัพธ์มากกว่าผู้ปฏิบัติงานแบบ Singleplex ทุกรายการที่ส่งไปยัง stderr จะเข้าไปอยู่ในไฟล์บันทึกเดียวที่แชร์ระหว่าง WorkerProxy ทั้งหมดที่เป็นประเภทเดียวกัน โดยจะแทรกสลับไปมาระหว่างคำขอหลายรายการพร้อมกัน แม้ว่าการเปลี่ยนเส้นทาง stdout ไปยัง stderr ก็เป็นความคิดที่ดี แต่อย่ารวบรวมเอาต์พุตนั้นลงในช่อง output ของ WorkResponse เนื่องจากอาจเป็นการแสดงผลลัพธ์ของผู้ใช้อย่างไม่คาดคิด
หากเครื่องมือของคุณส่งเฉพาะเอาต์พุตที่มุ่งเน้นผู้ใช้ไปยัง stdout หรือ stderr คุณจะต้องเปลี่ยนลักษณะการทำงานดังกล่าวก่อนจึงจะเปิดใช้ผู้ปฏิบัติงาน Multiplex ได้
การเปิดให้ผู้ปฏิบัติงาน Multiplex
ไม่ได้เปิดใช้ผู้ปฏิบัติงาน Multiplex ไว้โดยค่าเริ่มต้น ชุดกฎจะเปิดใช้ผู้ปฏิบัติงาน Multiplex ได้โดยใช้แท็ก supports-multiplex-workers ในการดำเนินงาน execution_requirements (เช่นเดียวกับแท็ก supports-workers ที่เปิดให้ผู้ปฏิบัติงานทั่วไป) ในกรณีที่ใช้ผู้ปฏิบัติงานทั่วไป คุณต้องระบุกลยุทธ์สำหรับผู้ปฏิบัติงานที่ระดับชุดกฎ (เช่น --strategy=[some_mnemonic]=worker) หรือที่ระดับกลยุทธ์ (เช่น --dynamic_local_strategy=worker,standalone) ไม่จำเป็นต้องมีแฟล็กเพิ่มเติม และ supports-multiplex-workers จะมีความสำคัญเหนือกว่า supports-workers หากคุณตั้งค่าทั้ง 2 อย่างไว้ คุณปิดผู้ปฏิบัติงาน Multiplex ทั่วโลกได้โดยส่ง --noworker_multiplex
เราขอแนะนำให้ชุดกฎใช้ผู้ปฏิบัติงาน Multiplex หากเป็นไปได้ เพื่อลดความกดดันของหน่วยความจำและปรับปรุงประสิทธิภาพ แต่ปัจจุบันผู้ปฏิบัติงาน Multiplex ยังใช้งานร่วมกับการดำเนินการแบบไดนามิกไม่ได้ เว้นแต่จะใช้แซนด์บ็อกซ์ Multiplex การพยายามเรียกใช้ผู้ปฏิบัติงาน Multiplex ที่ไม่ได้แซนด์บ็อกซ์ด้วยการดำเนินการแบบไดนามิกจะใช้ผู้ปฏิบัติงาน Singleplex แซนด์บ็อกซ์แทน
แซนด์บ็อกซ์ Multiplex
คุณสามารถแซนด์บ็อกซ์ผู้ปฏิบัติงาน Multiplex ได้โดยเพิ่มการรองรับที่ชัดเจนในการใช้งานสำหรับผู้ปฏิบัติงาน แม้ว่าแซนด์บ็อกซ์ของผู้ปฏิบัติงาน Singleplex จะทำได้โดยเรียกใช้กระบวนการของผู้ปฏิบัติงานแต่ละรายในแซนด์บ็อกซ์ของตนเอง แต่ผู้ปฏิบัติงาน Multiplex จะแชร์ไดเรกทอรีการทำงานของกระบวนการระหว่างคำขอหลายรายการพร้อมกัน หากต้องการอนุญาตแซนด์บ็อกซ์ของผู้ปฏิบัติงาน Multiplex ผู้ปฏิบัติงานต้องรองรับการอ่านและการเขียนจากไดเรกทอรีย่อยที่ระบุไว้ในคำขอแต่ละรายการ แทนที่จะทำในไดเรกทอรีที่ทำงานอยู่โดยตรง
หากต้องการรองรับแซนด์บ็อกซ์มัลติเพล็กซ์ ผู้ปฏิบัติงานต้องใช้ช่อง sandbox_dir จาก WorkRequest และใช้ช่องนั้นเป็นคำนำหน้าสำหรับการอ่านและเขียนไฟล์ทั้งหมด
แม้ว่าช่อง arguments และ inputs จะไม่มีการเปลี่ยนแปลงจากคำขอที่ไม่ได้แซนด์บ็อกซ์ แต่อินพุตจริงจะสัมพัทธ์กับ sandbox_dir ผู้ปฏิบัติงานต้องแปลเส้นทางไฟล์ที่พบใน arguments และ inputs เพื่ออ่านจากเส้นทางที่แก้ไขนี้ และต้องเขียนเอาต์พุตทั้งหมดที่สัมพันธ์กับ sandbox_dir ด้วย
ซึ่งรวมถึงเส้นทาง เช่น "." ตลอดจนเส้นทางที่พบในไฟล์ที่ระบุในอาร์กิวเมนต์ (เช่น อาร์กิวเมนต์ "argfile")
เมื่อผู้ปฏิบัติงานรองรับแซนด์บ็อกซ์มัลติเพล็กซ์ ชุดกฎจะประกาศการรองรับนี้ได้โดยการเพิ่ม supports-multiplex-sandboxing ไปยังการดำเนินการ execution_requirements จากนั้น Bazel จะใช้แซนด์บ็อกซ์แบบมัลติเพล็กซ์หากผ่านแฟล็ก --experimental_worker_multiplex_sandboxing หรือหากผู้ปฏิบัติงานมีการใช้ผู้ปฏิบัติงานกับการดำเนินการแบบไดนามิก
ไฟล์ผู้ปฏิบัติงานของผู้ปฏิบัติงาน Multiplex ที่ทำแซนด์บ็อกซ์จะยังคงสัมพันธ์กับไดเรกทอรีที่ใช้งานอยู่ของกระบวนการทำงาน ดังนั้น หากใช้ไฟล์ทั้งสำหรับการเรียกใช้ผู้ปฏิบัติงานและเป็นอินพุต คุณต้องระบุทั้งที่เป็นอินพุตในอาร์กิวเมนต์ Flagfile และใน tools, executable หรือ runfiles