หน้านี้อธิบายเกี่ยวกับผู้ปฏิบัติงานมัลติเพล็กซ์ วิธีเขียนความเข้ากันได้กับ Multiplex และวิธีแก้ปัญหาเบื้องต้นสำหรับข้อจำกัดบางอย่าง
ผู้ปฏิบัติงานมัลติเพล็กซ์ ช่วยให้ Bazel จัดการคำขอหลายรายการกับผู้ปฏิบัติงานคนเดียวได้ ขั้นตอนได้ สำหรับผู้ปฏิบัติงานแบบหลายชุดข้อความ Bazel จะใช้ทรัพยากรน้อยลงเพื่อทำสิ่งต่อไปนี้ได้ จะได้รับประสิทธิภาพ เท่าเดิมหรือดีขึ้น เช่น แทนที่จะมี กระบวนการของพนักงานต่อคนงาน Bazel สามารถมีพนักงานที่ใช้มัลติเพล็กซ์ได้ 4 คนพูดคุยด้วย กระบวนการของผู้ปฏิบัติงานคนเดียวกัน จึงจัดการคำขอไปพร้อมกันได้ สำหรับ ภาษาอย่าง Java และ Scala ทำให้ช่วยประหยัดเวลาอุ่นเครื่องของ JVM และการคอมไพล์ JIT และโดยทั่วไป Google Play ก็สามารถใช้ แคช ที่ใช้ร่วมกันระหว่างผู้ปฏิบัติงานทั้งหมดของ ประเภทเดียวกัน
ภาพรวม
เซิร์ฟเวอร์ Bazel และกระบวนการของพนักงานจะแบ่งเป็น 2 เลเยอร์ สำหรับบาง
การช่วยจำที่สามารถเรียกใช้กระบวนการได้พร้อมกัน Bazel จะได้รับ WorkerProxy จาก
พูลผู้ปฏิบัติงาน WorkerProxy จะส่งต่อคำขอไปยังกระบวนการของผู้ปฏิบัติงาน
ตามลำดับ พร้อมกับ request_id ผู้ปฏิบัติงานจะดำเนินการตามคำขอ
และส่งคำตอบไปยัง WorkerMultiplexer เมื่อWorkerMultiplexer
ได้รับการตอบกลับ ระบบจะแยกวิเคราะห์ request_id แล้วส่งต่อคําตอบ
กลับไปเป็น WorkerProxy ที่ถูกต้อง เช่นเดียวกับผู้ปฏิบัติงานที่ไม่ใช้มัลติเพล็กซ์
การสื่อสารจะกระทำผ่านมาตรฐานทั้งใน/ออก แต่เครื่องมือจะใช้
stderr สำหรับเอาต์พุตที่ผู้ใช้มองเห็นได้ (ดูด้านล่าง)
ผู้ปฏิบัติงานแต่ละคนจะมีคีย์ Bazel ใช้โค้ดแฮชของคีย์ (ประกอบด้วยสภาพแวดล้อม
ตัวแปร รากการดำเนินการ และเทคนิคการช่วยจำ) เพื่อพิจารณาว่า
WorkerMultiplexer WorkerProxy สื่อสารกับคนเดียวกัน
WorkerMultiplexer หากมีโค้ดแฮชเดียวกัน ดังนั้น สมมติว่า
ตัวแปรสภาพแวดล้อมและรากการดำเนินการเหมือนกันใน Bazel เดียว
แต่ละรายการจะมี WorkerMultiplexer และ 1 รายการเท่านั้นได้
ของผู้ปฏิบัติงาน จำนวนผู้ปฏิบัติงานทั้งหมด รวมถึงผู้ปฏิบัติงานปกติและ
WorkerProxy ยังคงถูกจำกัดโดย --worker_max_instances
การเขียนกฎที่ใช้ได้กับ Multiplex
กระบวนการทำงานของกฎควรเป็นแบบหลายชุดข้อความเพื่อใช้ประโยชน์จาก
ผู้ปฏิบัติงานมัลติเพล็กซ์ Protobuf อนุญาตให้ชุดกฎแยกวิเคราะห์คำขอเดียวได้
แต่อาจมีคำขอจำนวนมากหลั่งไหลเข้ามาในสตรีม เมื่อใดก็ตามที่
ผู้ปฏิบัติงานจะแยกวิเคราะห์คำขอจากสตรีม ซึ่งควรจัดการคำขอใน
ชุดข้อความใหม่ เนื่องจากชุดข้อความอื่นอาจเสร็จสมบูรณ์และเขียนไปยังสตรีมที่เวลา
ในขณะเดียวกัน พนักงานก็จำเป็นต้องตรวจสอบว่าได้เขียนคำตอบแล้ว
ปรมาณู (ข้อความไม่ซ้อนทับกัน) คำตอบต้องมีฟิลด์
request_id ของคำขอที่จัดการอยู่
การจัดการเอาต์พุต 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) ไม่มีการตั้งค่าสถานะเพิ่มเติม
และ supports-multiplex-workers จะมีความสำคัญเหนือกว่า
supports-workers หากตั้งค่าไว้ทั้ง 2 อย่าง คุณปิดผู้ปฏิบัติงานมัลติเพล็กซ์ได้
ทั่วโลก โดยผ่าน --noworker_multiplex
หากเป็นไปได้ เราขอแนะนำให้ชุดกฎใช้ผู้ปฏิบัติงาน Multiplex เพื่อลดหน่วยความจำ แรงกดดันและปรับปรุงประสิทธิภาพ อย่างไรก็ตาม ขณะนี้ผู้ปฏิบัติงานมัลติเพล็กซ์ไม่ได้เป็น ใช้ได้กับการดำเนินการแบบไดนามิก เว้นแต่จะ ใช้แซนด์บ็อกซ์แบบมัลติเพล็กซ์ พยายามเรียกใช้มัลติเพล็กซ์ที่ไม่ใช่แซนด์บ็อกซ์ ผู้ปฏิบัติงานที่มีการดำเนินการแบบไดนามิกจะใช้แซนด์บ็อกซ์โดยไม่มีการแจ้งเตือน Singleplex แทน
แซนด์บ็อกซ์ 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 ไปแล้ว หรือหาก
จะมีการใช้ผู้ปฏิบัติงานกับการดำเนินการแบบไดนามิก
ไฟล์ผู้ปฏิบัติงานของผู้ปฏิบัติงาน Multiplex ที่ทำแซนด์บ็อกซ์ยังคงเกี่ยวข้องกับ
ของกระบวนการทำงานของผู้ปฏิบัติงาน ดังนั้น หากไฟล์
ซึ่งใช้ทั้งเพื่อเรียกใช้งานผู้ปฏิบัติงานและเป็นอินพุต ต้องระบุทั้งคู่เป็น
อินพุตในอาร์กิวเมนต์ Flagfile รวมถึงใน tools, executable หรือ
runfiles