Score:0

พิจารณาประสิทธิภาพของแพลตฟอร์มตาม Nginx - ngx_http_stub_status_module

ธง cn

Nginx ถูกวางไว้หน้าสถาปัตยกรรมไมโครเซอร์วิสที่เราไม่มีข้อมูลเชิงลึก เราดึงเมตริกที่เปิดเผยโดย สถานะต้นขั้ว http และต้องการคำนวณตัวบ่งชี้ประสิทธิภาพของแพลตฟอร์ม: เราไม่สามารถใช้เวลาแฝงในการทดสอบโหลดเนื่องจากเราต้องการเปรียบเทียบไซต์ที่แตกต่างกันตามภูมิศาสตร์

สิ่งที่เราพยายามจนถึงตอนนี้:

  • คำนวณเดลต้าของคำขอทั้งหมดต่อหน่วยเวลา ปัญหา: มันไม่ได้สะท้อนถึงประสิทธิภาพ ทุกไซต์ใช้จำนวนคำขอเดียวกัน (100req ต่อ 100ms)
  • ใช้มาตรวัดการเชื่อมต่อที่รอ*

*ด้วยตัวบ่งชี้นี้ เราสังเกตพฤติกรรมต่างๆ สองขั้วคือ:

เซิร์ฟเวอร์ 2012 (E5-2620 v1, 24 เธรด) : เฉลี่ย 68,62 การเชื่อมต่อที่รอต่อ 100ms

เซิร์ฟเวอร์ 2021 (AMD EPYC 7642, 96 เธรด) : เฉลี่ย 91,96 การเชื่อมต่อที่รอต่อ 100ms

คำถามแรก ดูเหมือนว่ามาตรวัดควรอ่านว่า "ยิ่งสูงยิ่งดี" ทำไม เอกสารไม่ได้ให้รายละเอียด แต่ตามความรู้ของเรา การเชื่อมต่อที่รอคำตอบควรปรากฏที่นี่ หรือมาตรวัดนี้ประกอบด้วยการเชื่อมต่อที่ไม่ได้ใช้งานเท่านั้น (เช่น การเชื่อมต่อที่ใช้งานแล้ว)

คำถามที่สอง ในการทดสอบโหลดเดียวกัน เมตริกการเชื่อมต่อที่ยอมรับ/จัดการจะสูงกว่ามากในเซิร์ฟเวอร์ล่าสุด (ประมาณสองเท่า) ทำไม ทั้งคู่ให้บริการคำขอจำนวนเท่ากันที่ส่งมาจากกลุ่มการเชื่อมต่อ 100 รายการ สิ่งที่เราเห็นคือจำนวนของการเชื่อมต่อที่จัดการมีความคืบหน้าอย่างรวดเร็วในตอนเริ่มต้น จนถึงค่าเพดานที่แตกต่างกันขึ้นอยู่กับสถาปัตยกรรม และหลังจากนั้นความคืบหน้าจะค่อนข้างเป็นเส้นตรง เราไม่พบคำอธิบายใด ๆ ของพฤติกรรมนี้ที่แสดงบนกราฟนี้: กราฟของการเชื่อมต่อที่จัดการ

Score:0
ธง cn

เราไม่สามารถใช้เวลาแฝงในการทดสอบโหลดตามที่เราต้องการเปรียบเทียบ ไซต์ที่แตกต่างกันทางภูมิศาสตร์

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

[การเชื่อมต่อที่รอ] ควรอ่านว่า "ยิ่งสูงยิ่งดี" ทำไม

กำลังอ่านและเขียนการเชื่อมต่อที่ใช้งานอยู่กำลังทำ I/O กำลังทำงาน การรอคอยคือการมีชีวิตอยู่ การรอคอยลูกค้า หลังจากที่พวกเขาได้ดำเนินการตามคำขอเรียบร้อยแล้ว

ที่ระดับคำขอต่อวินาทีที่เท่ากัน การอ่านและเขียนที่ต่ำกว่านั้นดี เพราะนั่นสัมพันธ์กับการเชื่อมต่อที่ให้บริการอย่างรวดเร็ว นั่นอาจหมายถึงการรอลูกค้ามากขึ้น จำนวนการรอก็มากขึ้น แต่จำนวนการเชื่อมต่อก็มีจำกัด

คำถามที่สอง ในการทดสอบโหลดเดียวกัน การเชื่อมต่อที่ยอมรับ/จัดการ เมตริกจะสูงกว่ามากในเซิร์ฟเวอร์ล่าสุด (ประมาณสองเท่า) ทำไม

สองสามวินาทีแรกของการเชื่อมต่อทั้งสองในช่วงเวลานั้นค่อนข้างผิดปกติ กระโดดขึ้นมาใกล้ทันที ฉันไม่ชัดเจนว่าทำไมสิ่งนี้ถึงเกิดขึ้น แต่บางที nginx อาจทำงานนานกว่าก่อนการทดสอบดังนั้นตัวนับจึงสูงขึ้น

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

PierreJ avatar
cn flag
คุณพูดถูก เวลาตอบกลับเป็นเมตริกที่มีประโยชน์ เราจัดการเพื่อหลีกเลี่ยงการกระจายทางสถิติที่ซับซ้อนที่สุดโดยการคำนวณเวลาตอบสนองจากมุมมองของ nginx (แทนมุมมองของไคลเอ็นต์) โดยใช้ [โมดูล](https://github.com/knyar/nginx-lua-prometheus) นี้

โพสต์คำตอบ

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