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