หน้านี้อธิบายเกี่ยวกับผู้ปฏิบัติงานมัลติเพล็กซ์ วิธีเขียนกฎที่ใช้กับ 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 ใช้โค้ดแฮชของคีย์ (ประกอบขึ้นจากตัวแปรสภาพแวดล้อม รูทการดำเนินการ และ Mnemonic) เพื่อกำหนด WorkerMultiplexer ที่จะใช้ โดย WorkerProxy จะสื่อสารกับ WorkerMultiplexer เดียวกันหากมีโค้ดแฮชเดียวกัน ดังนั้น สมมติว่าตัวแปรสภาพแวดล้อมและรูทการดำเนินการเหมือนกันในการเรียกใช้ Bazel เดียว การช่วยจำที่ไม่ซ้ำกันแต่ละรายการจะมีกระบวนการ WorkerMultiplexer และผู้ปฏิบัติงานได้เพียง 1 กระบวนการ จำนวนผู้ปฏิบัติงานทั้งหมด รวมถึงผู้ปฏิบัติงานปกติและ WorkerProxy ยังคงถูกจำกัดโดย --worker_max_instances
การเขียนกฎที่ใช้ได้กับ Multiplex
กระบวนการทำงานของกฎควรเป็นแบบหลายชุดข้อความเพื่อใช้ประโยชน์จากผู้ปฏิบัติงานมัลติเพล็กซ์ Protobuf ทำให้ชุดกฎแยกวิเคราะห์คำขอเดียวได้แม้ว่าจะอาจมีคำขอหลายรายการสะสมอยู่ในสตรีมก็ตาม เมื่อใดก็ตามที่ผู้ปฏิบัติงานแยกวิเคราะห์คำขอจากสตรีม ผู้ปฏิบัติงานควรจัดการคำขอในชุดข้อความใหม่ เนื่องจากชุดข้อความต่างๆ อาจสร้างเสร็จและเขียนไปยังสตรีมพร้อมกันได้ กระบวนการของผู้ปฏิบัติงานจึงต้องเขียนคำตอบให้เป็นแบบอะตอม (ข้อความจะไม่ซ้อนทับกัน) คำตอบต้องมี request_id ของคำขอที่จัดการอยู่
การจัดการเอาต์พุต Multiplex
ผู้ปฏิบัติงาน Multiplex ต้องระมัดระวังเรื่องการจัดการเอาต์พุตมากกว่าผู้ปฏิบัติงาน Singleplex ทุกรายการที่ส่งไปยัง stderr จะอยู่ในไฟล์บันทึกเดียวที่แชร์ในกลุ่ม WorkerProxy ทั้งหมดที่อยู่ในประเภทเดียวกัน โดยจะแทรกสลับกันระหว่างคำขอหลายรายการพร้อมกัน ในขณะที่การเปลี่ยนเส้นทาง stdout ไปยัง stderr เป็นความคิดที่ดี โปรดอย่ารวบรวมเอาต์พุตนั้นในช่อง output ของ WorkResponse เนื่องจากอาจทำให้ผู้ใช้ได้รับเอาต์พุตที่ยุ่งยาก
หากเครื่องมือส่งเฉพาะเอาต์พุตที่มุ่งเน้นผู้ใช้ไปยัง stdout หรือ stderr คุณจะต้องเปลี่ยนลักษณะการทำงานดังกล่าวก่อนจึงจะเปิดใช้ผู้ปฏิบัติงาน Multiplex ได้
การเปิดใช้ผู้ปฏิบัติงาน Multiplex
ไม่ได้เปิดใช้ผู้ปฏิบัติงาน Multiplex โดยค่าเริ่มต้น ชุดกฎจะเปิดใช้งานผู้ปฏิบัติงานแบบมัลติเพล็กซ์ได้โดยใช้แท็ก supports-multiplex-workers ใน execution_requirements ของการดำเนินการ (เช่นเดียวกับที่แท็ก supports-workers เปิดใช้ผู้ปฏิบัติงานทั่วไป) ในกรณีที่ใช้ผู้ปฏิบัติงานทั่วไป คุณต้องระบุกลยุทธ์ผู้ปฏิบัติงานที่ระดับชุดกฎ (เช่น --strategy=[some_mnemonic]=worker) หรือโดยทั่วไปที่ระดับกลยุทธ์ (เช่น --dynamic_local_strategy=worker,standalone) ไม่จำเป็นต้องมี Flag เพิ่มเติมและ supports-multiplex-workers จะมีความสำคัญสูงกว่า supports-workers หากตั้งค่าทั้ง 2 อย่างไว้ คุณสามารถปิดผู้ปฏิบัติงานมัลติเพล็กซ์
ทั่วโลกได้โดยส่ง --noworker_multiplex
เราขอแนะนำให้ชุดกฎใช้ผู้ปฏิบัติงานมัลติเพล็กซ์หากเป็นไปได้ เพื่อลดการใช้หน่วยความจำและปรับปรุงประสิทธิภาพ อย่างไรก็ตาม ขณะนี้ผู้ปฏิบัติงานมัลติเพล็กซ์ยังใช้งานร่วมกับการดำเนินการแบบไดนามิกไม่ได้ เว้นแต่จะใช้แซนด์บ็อกซ์แบบมัลติเพล็กซ์ การพยายามเรียกใช้ผู้ปฏิบัติงานมัลติเพล็กซ์ที่ไม่ใช่แซนด์บ็อกซ์ด้วยการดำเนินการแบบไดนามิกจะใช้ผู้ปฏิบัติงาน Singleplex ที่เป็นแซนด์บ็อกซ์แทน
แซนด์บ็อกซ์ Multiplex
คุณสามารถใช้แซนด์บ็อกซ์ของผู้ปฏิบัติงาน Multiplex โดยเพิ่มการสนับสนุนอย่างชัดแจ้งสำหรับผู้ปฏิบัติงานดังกล่าวในการใช้งาน แม้ว่าแซนด์บ็อกซ์ของผู้ปฏิบัติงาน Singleplex จะทําได้โดยเรียกใช้กระบวนการของผู้ปฏิบัติงานแต่ละกระบวนการในแซนด์บ็อกซ์ของตัวเอง แต่ผู้ปฏิบัติงานมัลติเพล็กซ์จะแชร์ไดเรกทอรีการทํางานของกระบวนการระหว่างคําขอที่โหลดพร้อมกันหลายรายการ หากต้องการอนุญาตให้ใช้แซนด์บ็อกซ์ของผู้ปฏิบัติงานมัลติเพล็กซ์ ผู้ปฏิบัติงานต้องรองรับการอ่านและการเขียนไปยังไดเรกทอรีย่อยที่ระบุไว้ในแต่ละคำขอ แทนที่จะรองรับในไดเรกทอรีที่ใช้งานอยู่โดยตรง
หากต้องการรองรับแซนด์บ็อกซ์แบบมัลติเพล็กซ์ ผู้ปฏิบัติงานต้องใช้ช่อง 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 ด้วย