OpenTelemetry Go SDK แสดงค่าโอเวอร์เฮดของ CPU 30% ในการทดสอบประสิทธิภาพ จุดประกายการถdebateเรื่องการปรับปรุงประสิทธิภาพในชุมชน

ทีมบรรณาธิการ BigGo
OpenTelemetry Go SDK แสดงค่าโอเวอร์เฮดของ CPU 30% ในการทดสอบประสิทธิภาพ จุดประกายการถdebateเรื่องการปรับปรุงประสิทธิภาพในชุมชน

การทดสอบประสิทธิภาพล่าสุดของ OpenTelemetry Go SDK เผยให้เห็นค่าใช้จ่ายด้านโอเวอร์เฮดที่สำคัญ ซึ่งกำลังจุดประกายการถกเถียงอย่างเข้มข้นในหมู่นักพัฒนาเกี่ยวกับกลยุทธ์การปรับปรุงประสิทธิภาพและแนวทางทางเลือก การทดสอบที่วัดเซิร์ฟเวอร์ HTTP อย่างง่ายที่จัดการคำขอ 10,000 ครั้งต่อวินาที แสดงให้เห็นผลกระทบด้านประสิทธิภาพที่ชัดเจนเมื่อเปิดใช้งานฟีเจอร์ observability แบบเต็มรูปแบบ

ผลการทดสอบได้ดึงดูดความสนใจของชุมชน Go โดยเฉพาะอย่างยิ่งเพราะพวกเขาเน้นย้ำถึงต้นทุนในโลกแห่งความเป็นจริงที่หลายทีมต้องเผชิญเมื่อนำ observability แบบครอบคลุมมาใช้งาน แม้ว่าโอเวอร์เฮดจะไม่จำเป็นต้องเป็นอุปสรรค แต่ก็มีความสำคัญพอที่จะส่งผลกระทบในระดับขนาดใหญ่

การกำหนดค่าการทดสอบ

  • Load: 10,000 requests ต่อวินาที
  • Infrastructure: 4 โหนด Linux (2 vCPU, 8GB RAM แต่ละโหนด)
  • Components: Go HTTP server, Volkey database, wrk2 load generator
  • Duration: 20 นาทีต่อการทดสอบ
  • Network: โหมด Host network เพื่อหลีกเลี่ยง Docker proxy overhead
กราฟแสดงการใช้งาน CPU ตามช่วงเวลา เน้นให้เห็นค่าใช้จ่ายด้านประสิทธิภาพเมื่อเปิดใช้งานฟีเจอร์การสังเกตการณ์แบบเต็มรูปแบบ
กราฟแสดงการใช้งาน CPU ตามช่วงเวลา เน้นให้เห็นค่าใช้จ่ายด้านประสิทธิภาพเมื่อเปิดใช้งานฟีเจอร์การสังเกตการณ์แบบเต็มรูปแบบ

การใช้งาน CPU เพิ่มขึ้น 30% ด้วย Full Instrumentation

การค้นพบที่โดดเด่นที่สุดคือโอเวอร์เฮดของ CPU เมื่อเปิดใช้งาน OpenTelemetry tracing การใช้งาน CPU เพิ่มขึ้นจาก 2 cores เป็นประมาณ 2.7 cores ซึ่งเพิ่มขึ้น 30% การเพิ่มขึ้นนี้มาจากการประมวลผล span การส่งออกข้อมูล และการดำเนินการที่มี instrumentation เช่นการเรียก Redis ซึ่งเห็นโอเวอร์เฮดเพิ่มเติมประมาณ 7%

สมาชิกในชุมชนเสนอแนวทางแก้ไขเพื่อลดผลกระทบนี้แล้ว นักพัฒนาคนหนึ่งได้ระบุโอกาสในการปรับปรุงหลายประการ รวมถึงการใช้ฟังก์ชันเวลาที่เร็วกว่า การแทนที่ mutex locks ด้วย atomic operations และการใช้งาน direct protocol buffer marshaling แทนแนวทางที่ใช้ reflection

การแบ่งแยกภาระงาน CPU

  • การประมวลผล Span: ~10% ของเวลา CPU ทั้งหมด
  • การดำเนินการ Redis: ภาระงานเพิ่มขึ้น +7% ในการเรียกใช้ go-redis
  • ตัวจัดการ HTTP: ภาระงานเพิ่มเติมจาก middleware ที่มีการติดตั้งเครื่องมือ
  • ทางเลือก eBPF: ภาระงาน <0.2 cores (ต่ำกว่าอย่างมีนัยสำคัญ)

ค่าใช้จ่าย Memory และ Network สะสมขึ้น

นอกเหนือจากการใช้งาน CPU แล้ว การทดสอบยังเผยให้เห็นผลกระทบด้านทรัพยากรอื่นๆ การใช้ memory เพิ่มขึ้นจาก 10MB เป็น 15-50MB ในขณะที่ network traffic เพิ่มขึ้นอย่างมีนัยสำคัญด้วยข้อมูล telemetry 4MB ต่อวินาทีที่ถูกส่งออก สำหรับบริการที่มี throughput สูงหรือสภาพแวดล้อมที่มีข้อจำกัดด้าน network อย่างเข้มงวด การใช้ bandwidth เพิ่มเติมนี้กลายเป็นข้อพิจารณาที่แท้จริง

ผลกระทบด้าน latency ค่อนข้างเจียมเนื้อเจียมตัวแต่ยังคงวัดได้ เวลาตอบสนองที่ percentile ที่ 99 เพิ่มขึ้นจาก 10 มิลลิวินาทีเป็นประมาณ 15 มิลลิวินาที แม้ว่า throughput โดยรวมจะยังคงเสถียรที่ประมาณ 11,800 คำขอต่อวินาที

สรุปผลกระทบต่อประสิทธิภาพ

  • การใช้งาน CPU: เพิ่มขึ้นจาก 2.0 เป็น 2.7 cores (+30%)
  • การใช้งานหน่วยความจำ: เพิ่มขึ้นจาก ~10MB เป็น 15-50MB
  • ปริมาณการรับส่งข้อมูลเครือข่าย: เพิ่ม 4MB/วินาที (32 Mbps) สำหรับข้อมูล telemetry
  • เวลาตอบสนอง (p99): เพิ่มขึ้นจาก 10ms เป็น 15ms
  • อัตราการประมวลผล: คงที่ที่ ~11,800 requests ต่อวินาที

กลยุทธ์ Sampling กลายเป็นสิ่งสำคัญ

การอภิปรายในชุมชนได้เน้นย้ำถึงช่องว่างที่สำคัญในการทดสอบ: มันไม่ได้นำกลยุทธ์ sampling ที่ระบบ production ส่วนใหญ่ใช้มาใช้งาน นักพัฒนาที่มีประสบการณ์หลายคนชี้ให้เห็นว่าการ trace ทุกคำขอเดียวในปริมาณสูงไม่ใช่สิ่งที่สมจริงหรือจำเป็น

การ trace ทุก http 200 ที่ 10k req/sec ไม่ใช่สิ่งที่คุณควรทำ ในอัตรานั้นคุณควร sample 200 (1% หรือประมาณนั้น) และ trace error ทั้งหมด

อย่างไรก็ตาม การนำ smart sampling มาใช้งานมีความซับซ้อนในตัวเอง ทีมต้องการจับ error ทั้งหมด แต่คุณไม่รู้ว่าคำขอจะ error จนกว่าจะเสร็จสิ้น สิ่งนี้สร้างปัญหาไก่กับไข่ที่ต้องการระบบ tail-based sampling ที่ซับซ้อน

eBPF เกิดขึ้นเป็นทางเลือกที่เบา

การทดสอบยังทดสอบ eBPF-based instrumentation เป็นแนวทางทางเลือก เทคนิคการตรวจสอบระดับ kernel นี้แสดงโอเวอร์เฮดที่ต่ำกว่ามาก - อยู่ภายใต้ 0.2 CPU cores แม้ภายใต้โหลดหนัก แม้ว่า eBPF จะไม่สามารถให้ tracing ที่ละเอียดเหมือนแนวทางที่ใช้ SDK แต่ก็เสนอจุดกึ่งกลางที่ปฏิบัติได้สำหรับทีมที่ต้องการการมองเห็นโดยไม่มีต้นทุนด้านประสิทธิภาพ

การแลกเปลี่ยนระหว่าง observability ที่ละเอียดและประสิทธิภาพของระบบยังคงเป็นความท้าทายสำหรับทีมพัฒนา องค์กรบางแห่ง โดยเฉพาะใน high-frequency trading และ ad-tech พบว่าโอเวอร์เฮดของ tracing แบบดั้งเดิมไม่สามารถยอมรับได้อย่างสิ้นเชิง ทำให้โซลูชันที่ใช้ eBPF มีความน่าสนใจมากขึ้น

ความท้าทายด้านการปรับปรุงข้างหน้า

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

ความท้าทายอยู่ที่การสร้างสมดุลระหว่างความซับซ้อนของการปรับปรุงกับความสามารถในการบำรุงรักษา แม้ว่า atomic operations และ custom marshaling สามารถเพิ่มประสิทธิภาพได้ แต่พวกเขายังแนะนำข้อบกพร่องที่ละเอียดอ่อนและโอเวอร์เฮดการบำรุงรักษาที่โปรเจกต์ open-source ต้องพิจารณาอย่างรอบคอบ

สำหรับทีมส่วนใหญ่ โอเวอร์เฮดปัจจุบันแสดงถึงการแลกเปลี่ยนที่จัดการได้สำหรับความสามารถในการ debug และ monitoring ที่ OpenTelemetry ให้ อย่างไรก็ตาม เมื่อแอปพลิเคชันขยายขนาดและข้อกำหนดด้านประสิทธิภาพเข้มงวดขึ้น การอภิปรายเรื่องการปรับปรุงเหล่านี้จะมีความสำคัญมากขึ้นสำหรับการนำไปใช้ในอนาคตของโปรเจกต์

อ้างอิง: OpenTelemetry for Go: measuring the overhead