การแยกเมตริกประสิทธิภาพของบิลด์

รายงานปัญหา ดูแหล่งที่มา

ผู้ใช้ Bazel ทุกคนคงเคยพบกับบิวด์ที่ช้าหรือช้ากว่าที่คาดไว้ การปรับปรุงประสิทธิภาพของบิลด์แต่ละรายการมีคุณค่าเฉพาะต่อเป้าหมายที่มีผลกระทบอย่างมาก เช่น

  1. เป้าหมายหลักของนักพัฒนาแอปที่มักทำซ้ำและสร้าง (ใหม่) อยู่บ่อยครั้ง

  2. ไลบรารีทั่วไปจะขึ้นอยู่กับเป้าหมายอื่นๆ อย่างกว้างขวาง

  3. เป้าหมายที่เป็นตัวแทนจากคลาสของเป้าหมาย (เช่น กฎที่กำหนดเอง) การวินิจฉัยและแก้ไขปัญหาในบิลด์หนึ่งอาจช่วยแก้ปัญหาในวงกว้างได้

ขั้นตอนสำคัญในการปรับปรุงประสิทธิภาพของบิลด์คือการทำความเข้าใจพื้นที่ที่ใช้ทรัพยากร หน้านี้จะแสดงเมตริกต่างๆ ที่คุณรวบรวมได้ การแจกแจงประสิทธิภาพของบิลด์จะแสดงวิธีใช้เมตริกเหล่านี้เพื่อตรวจหาและแก้ไขปัญหาด้านประสิทธิภาพของบิลด์

วิธีการหลักๆ ในการแยกเมตริกจากบิลด์ของ Bazel ได้แก่

โปรโตคอลเหตุการณ์บิวด์ (BEP)

Bazel แสดงผลบัฟเฟอร์โปรโตคอลที่หลากหลาย build_event_stream.proto ผ่านโปรโตคอลเหตุการณ์สร้าง (BEP) ซึ่งรวบรวมโดยแบ็กเอนด์ที่คุณระบุได้ คุณอาจตัดสินใจที่จะรวมเมตริกด้วยวิธีต่างๆ โดยขึ้นอยู่กับกรณีการใช้งานของคุณ แต่ในที่นี้เราจะพูดถึงแนวคิดและฟิลด์ Proto บางส่วนที่จะเป็นประโยชน์ในการนำไปพิจารณาโดยทั่วไป

คำสั่งของ Bazel / cquery / aquery

Bazel มีโหมดการค้นหา 3 โหมด (query, cquery และ aquery) ที่ช่วยให้ผู้ใช้ค้นหากราฟเป้าหมาย กราฟเป้าหมายที่กำหนดค่าไว้ และกราฟการดำเนินการตามลำดับ ภาษาในการค้นหามีชุดฟังก์ชันที่ใช้งานได้ในโหมดการค้นหาต่างๆ ซึ่งช่วยให้คุณปรับแต่งคำค้นหาได้ตามความต้องการ

โปรไฟล์การติดตาม JSON

สำหรับทุกการเรียกใช้ Bazel ที่เหมือนบิลด์ Bazel จะเขียนโปรไฟล์การติดตามในรูปแบบ JSON โปรไฟล์การติดตาม JSON จะมีประโยชน์มากในการทำความเข้าใจอย่างรวดเร็วว่า Bazel ทำอะไรระหว่างการเรียกใช้

บันทึกการดำเนินการ

บันทึกการดำเนินการจะช่วยคุณแก้ปัญหาและแก้ไข Hit ของแคชระยะไกลที่หายไปเนื่องจากความแตกต่างของเครื่องและสภาพแวดล้อม หรือการดำเนินการที่ไม่ได้กำหนด หากคุณส่งแฟล็ก --experimental_execution_log_spawn_metrics (พร้อมใช้งานจาก Bazel 5.2) ก็จะมีเมตริกการสร้างโดยละเอียดทั้งสำหรับการดำเนินการที่ดำเนินการในเครื่องและจากระยะไกล คุณสามารถใช้เมตริกเหล่านี้ในการเปรียบเทียบประสิทธิภาพของเครื่องแบบในเครื่องและระยะไกล หรือดูว่าส่วนใดของการดำเนินการที่สร้างขึ้นซึ่งช้ากว่าที่คาดไว้อย่างสม่ำเสมอ (เช่น เนื่องจากการจัดคิว)

บันทึกกราฟการดำเนินการ

แม้ว่าโปรไฟล์การติดตาม JSON จะมีข้อมูลเส้นทางวิกฤติ แต่ในบางครั้งคุณก็ต้องการข้อมูลเพิ่มเติมเกี่ยวกับกราฟทรัพยากร Dependency ของการดำเนินการที่ดำเนินการไปแล้ว ตั้งแต่ Bazel 6.0 เป็นต้นไป คุณจะส่งแฟล็ก --experimental_execution_graph_log และ --experimental_execution_graph_log_dep_type=all เพื่อเขียนบันทึกเกี่ยวกับการดำเนินการที่ดำเนินการและการขึ้นต่อกันระหว่างการดำเนินการได้

ข้อมูลนี้สามารถใช้ทำความเข้าใจการลากที่เพิ่มโดยโหนดบนเส้นทางวิกฤติได้ การลากคือระยะเวลาที่อาจประหยัดได้โดยนำโหนดที่เฉพาะเจาะจงออกจากกราฟการดำเนินการ

ข้อมูลนี้ช่วยให้คุณสามารถคาดการณ์ผลกระทบของการเปลี่ยนแปลงที่มีต่อกราฟการสร้างและการกระทำก่อนที่คุณจะดำเนินการจริง

การเปรียบเทียบด้วยม้านั่งแบบเบเซล

Bazel bench เป็นเครื่องมือการเปรียบเทียบสำหรับโปรเจ็กต์ Git เพื่อใช้เปรียบเทียบประสิทธิภาพของบิลด์ในกรณีต่อไปนี้

  • การเปรียบเทียบโครงการ: การเปรียบเทียบ 2 git จะนำมาซึ่งกันและกันที่ Bazel เวอร์ชันเดียว ใช้เพื่อตรวจหาการถดถอยในบิลด์ (มักจะผ่านการเพิ่มทรัพยากร Dependency)

  • การเปรียบเทียบ Bazel: การเปรียบเทียบ Bazel 2 เวอร์ชันซึ่งกันและกันที่คอมมิตแบบ Git เดียว ใช้เพื่อตรวจหาการถดถอยภายใน Bazel (หากคุณต้องบำรุงรักษา / แยก Bazel)

การเปรียบเทียบจะตรวจสอบเวลาจริง เวลา CPU และเวลาของระบบ และขนาดฮีปที่คงอยู่ของ Bazel

นอกจากนี้ ขอแนะนำให้ใช้ Bazel bench บนเครื่องที่เป็นตัวจริงโดยเฉพาะซึ่งไม่ได้เรียกใช้กระบวนการอื่น เพื่อลดแหล่งที่มาของความแปรปรวน