Appdex (ดัชนีประสิทธิภาพการใช้งาน): คู่มือทางเทคนิคและมาตรฐานเมตริกฉบับสมบูรณ์

Apdex (Application Performance Index) เป็นมาตรฐานอุตสาหกรรมแบบเปิดที่พัฒนาโดยพันธมิตรของบริษัทซอฟต์แวร์ระดับองค์กร เพื่อวัดความพึงพอใจของผู้ใช้ต่อเวลาตอบสนองของเว็บแอปพลิเคชันและบริการด้านไอที

แทนที่จะอาศัยตัวชี้วัดเวลาตอบสนองโดยเฉลี่ยหรือเปอร์เซ็นไทล์เพียงอย่างเดียว Apdex แปลงตัวชี้วัดเวลาแฝงทางเทคนิคให้เป็นคะแนนมาตรฐานเดียวระหว่าง 0.0 (ยอมรับไม่ได้) ถึง 1.0 (ดีเยี่ยม) ซึ่งสะท้อนถึงความพึงพอใจของผู้ใช้ปลายทางโดยตรง

ตอบ-สรุปข้อแรก

คะแนน Apdex จะแปลงเวลาตอบสนองของแอปพลิเคชันให้เป็นตัวชี้วัดมาตรฐานตัวเดียวระหว่าง 0.00 ถึง 1.00 เพื่อวัดความพึงพอใจของผู้ใช้คำขอแบ่งออกเป็น พอใจ ($\le T$), ความอดทน ($> T \text{ และ } \le 4T$) และ หงุดหงิด ($> 4T$ หรือข้อผิดพลาด HTTP 5xx) ตามเวลาตอบสนองเป้าหมาย $T$ (โดยทั่วไปคือ 200ms ถึง 500ms)สูตรคือ $\text {Apdex} _T = (\text {Satisfied} + (\text {Tolerating} / 2)) / \text{ตัวอย่างทั้งหมด}$คะแนน Apdex ที่สูงกว่า 0.94 แสดงถึงประสิทธิภาพที่ยอดเยี่ยม ในขณะที่คะแนนที่ต่ำกว่า 0.70 บ่งชี้ถึงความหงุดหงิดของผู้ใช้อย่างรุนแรงซึ่งจำเป็นต้องเพิ่มประสิทธิภาพทางวิศวกรรมทันที

วิธีคำนวณคะแนน Apdex

การคำนวณ Apdex จะจัดหมวดหมู่คำขอของผู้ใช้ทุกรายการให้เป็นหนึ่งในสามโซนประสิทธิภาพที่แตกต่างกัน โดยอิงตามเกณฑ์เป้าหมายเวลาตอบสนองที่กำหนดไว้ $T$ (เช่น $200\text {ms} $):

1. พอใจ: คำขอที่มีเวลาตอบกลับ $\le T$ผู้ใช้สัมผัสได้ถึงการตอบสนองที่ดีที่สุดและดำเนินการตามขั้นตอนการทำงานโดยไม่ลังเลใจ
2. การยอมรับ: คำขอที่มีเวลาตอบสนอง $> T$ และ $\le 4T$ผู้ใช้สังเกตเห็นความล่าช้าเล็กน้อย แต่สามารถทำงานให้เสร็จสิ้นได้โดยไม่ต้องละทิ้งแอปพลิเคชัน
3. หงุดหงิด: คำขอที่มีเวลาตอบสนอง $> 4T$ หรือคำขอที่ส่งผลให้เกิดข้อผิดพลาด HTTP (รหัสสถานะ 5xx)ผู้ใช้พบกับความล่าช้าที่ไม่สามารถยอมรับได้หรือบริการขัดข้องโดยสิ้นเชิง

สูตรทางคณิตศาสตร์สำหรับคะแนน Apdex แสดงเป็น:

$$\text {Apdex} _T = \frac{\text{จำนวนที่พอใจ} + \frac{\text{จำนวนที่ยอมรับได้}}{2}}{\text{ตัวอย่างทั้งหมด}}$$

ตัวอย่างทางคณิตศาสตร์ที่ทำงาน

พิจารณาแอปพลิเคชัน SaaS ที่ได้รับคำขอ 10,000 รายการในช่วงเวลาการตรวจสอบหนึ่งชั่วโมงโดยมีเกณฑ์เป้าหมาย $T = 200\text {ms} $:

• คำขอที่พึงพอใจ ($\le 200\text {ms} $): 8,500
• คำขอที่ยอมรับได้ ($200\ข้อความ {ms} < t \le 800\ข้อความ {ms} $): 1,000
• คำขอที่หงุดหงิด ($> 800\ข้อความ {ms} ข้อผิดพลาด $ หรือ 5xx): 500

การเสียบค่าเหล่านี้เข้ากับสูตร Apdex จะได้ผลลัพธ์:

$$\text {Apdex} _ {200} = \frac{8500 + \frac {1000} {2}} {10000} = \frac{8500 + 500} {10000} = \frac{9000} {10000} = 0.90$$

คะแนน Apdex 0.90 อยู่ในหมวดหมู่ ดี ซึ่งบ่งชี้ว่าแม้ว่าผู้ใช้ส่วนใหญ่จะเพลิดเพลินกับประสบการณ์ที่รวดเร็ว แต่ 15% ของคำขอพบกับเวลาแฝงหรือข้อผิดพลาดที่ต้องมีการปรับให้เหมาะสม

ระดับคะแนนและหมวดหมู่คะแนน Apdex

Apdex Alliance กำหนดระดับคะแนนมาตรฐานห้าระดับเพื่อแปลคะแนนตัวเลขให้เป็นเป้าหมายทางวิศวกรรมที่นำไปปฏิบัติได้:

การเลือกเกณฑ์เป้าหมายที่ถูกต้อง $T$

การเลือกเกณฑ์เป้าหมายที่เหมาะสม $T$ เป็นสิ่งสำคัญสำหรับการได้รับคะแนน Apdex ที่ดำเนินการได้หาก $T$ ตั้งไว้สูงเกินไป (เช่น $2000\text {ms} $) คำขอที่ช้าจะถูกจัดประเภทอย่างไม่ถูกต้องเป็นพอใจในทางกลับกัน หากตั้งค่า $T$ ต่ำเกินไป (เช่น $20\text {ms} $) เวลาแฝงของเครือข่ายปกติจะลงโทษคะแนนแอปพลิเคชันของคุณโดยไม่จำเป็น

เกณฑ์เป้าหมายที่แนะนำตามประเภทแอปพลิเคชัน:

• API และไมโครเซอร์วิส: $T = 100\ข้อความ {ms} - 200\ข้อความ {ms} $
• แอปพลิเคชันเว็บ SaaS แบบโต้ตอบ: $T = 200\ข้อความ {ms} - 400\ข้อความ {ms} $
• หน้าผลิตภัณฑ์อีคอมเมิร์ซ: $T = 300\ข้อความ {ms} - 500\ข้อความ {ms} $
• แพลตฟอร์มสื่อและเนื้อหาจำนวนมาก: $T = 500\ข้อความ {ms} - 1,000\ข้อความ {ms} $

เหตุใด Apdex จึงมีประสิทธิภาพเหนือกว่าเวลาตอบสนองโดยเฉลี่ย

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

1. ค่าเบี่ยงเบนที่เบี่ยงเบน: การหมดเวลาเกิน 30 วินาทีที่รุนแรงเพียงจำนวนเล็กน้อยอาจทำให้เวลาตอบสนองโดยเฉลี่ยของคำขอ 50 มิลลิวินาทีที่รวดเร็วเพิ่มขึ้นอย่างเกินจริง ทำให้เกิดการแจ้งเตือนที่ผิดพลาด
2. การกระจายแบบสองรูปแบบ: เมื่อแอปพลิเคชันให้บริการสินทรัพย์คงที่ที่แคชไว้ใน 10 มิลลิวินาที และการสืบค้นฐานข้อมูลที่ซับซ้อนที่ไม่ได้แคชใน 2000 มิลลิวินาที ค่าเฉลี่ย 1,005 มิลลิวินาทีแสดงถึงประสบการณ์ของผู้ใช้ที่ไม่ถูกต้อง
3. การปรับมาตรฐานโดยยึดผู้ใช้เป็นศูนย์กลาง: Apdex ทำให้การวัดการตอบสนองเป็นคะแนน 0 ต่อ 1 ที่มนุษย์เข้าใจได้ ซึ่งผู้มีส่วนได้ส่วนเสียที่ไม่ใช่ด้านเทคนิค ผู้จัดการผลิตภัณฑ์ และผู้บริหารสามารถติดตามได้ตลอดเวลาโดยไม่ต้องอาศัยความเชี่ยวชาญด้านการวัดและส่งข้อมูลทางไกลเชิงลึก
4. การถ่วงน้ำหนักข้อผิดพลาด: Apdex จะถือว่าข้อผิดพลาดของเซิร์ฟเวอร์ HTTP 5xx และการหมดเวลาของเครือข่ายเป็นคำขอที่หงุดหงิดโดยอัตโนมัติ โดยบันทึกความล้มเหลวด้านความพร้อมใช้งานโดยตรงภายในดัชนีประสิทธิภาพ

Apdex กับ Core Web Vitals (LCP และ INP)

แม้ว่า Apdex เดิมจะได้รับการพัฒนาสำหรับเวลาตอบสนองฝั่งเซิร์ฟเวอร์และเครื่องมือ APM แต่วิศวกรรมประสิทธิภาพเว็บสมัยใหม่จำเป็นต้องรวม Apdex เข้ากับ Core Web Vitals ของ Google:

• Appdex: วัดเวลาตอบสนองของเซิร์ฟเวอร์แบ็กเอนด์และเวลาแฝงในการประมวลผล API ของคำขอ HTTP ทั้งหมด
• Largest Contentful Paint (LCP): วัดความเร็วในการโหลดภาพส่วนหน้าเมื่อองค์ประกอบเนื้อหาที่ใหญ่ที่สุดแสดงผลเสร็จสิ้นในวิวพอร์ตของผู้ใช้
• การโต้ตอบกับ Next Paint (INP): วัดการตอบสนองของ UI ส่วนหน้าระหว่างการโต้ตอบของผู้ใช้ (การคลิก การแตะ และการกดแป้นพิมพ์)

ด้วยการติดตาม Apdex สำหรับตำแหน่งข้อมูล Go/Gin API แบ็กเอนด์ของคุณควบคู่ไปกับ LCP และ INP สำหรับแอปพลิเคชัน Nuxt 4 ฟรอนต์เอนด์ของคุณ ทีมวิศวกรจะได้รับการมองเห็นตั้งแต่ต้นทางถึงปลายทางทั้งในด้านประสิทธิภาพฝั่งเซิร์ฟเวอร์และฝั่งไคลเอ็นต์

การรวม Apdex เข้ากับเวิร์กโฟลว์การตรวจสอบอย่างต่อเนื่อง

SimpleOps ติดตามคะแนน Apdex โดยอัตโนมัติจากตำแหน่งข้อมูล HTTP ที่ลงทะเบียนไว้ เส้นทางแอปพลิเคชันเว็บ และไมโครเซอร์วิส API ทั้งหมดของคุณด้วยการรวมโพรบสังเคราะห์ที่ส่ง Ping จากตำแหน่งตรวจสอบทั่วโลกมากกว่า 15 แห่งเข้ากับการวัดและส่งข้อมูลทางไกลของผู้ใช้จริง SimpleOps จะแจ้งเตือนทีมวิศวกรของคุณผ่านทาง Slack, Telegram หรือ Webhooks เมื่อใดก็ตามที่คะแนน Apdex ของแอปพลิเคชันของคุณลดลงต่ำกว่าเกณฑ์ SLO ที่คุณกำหนดค่าไว้

ด้วยการตรวจสอบ Apdex ควบคู่ไปกับสถานะการออนไลน์และ Core Web Vitals ทีม DevOps จะได้รับการมองเห็นที่สมบูรณ์ทั้งในด้านความพร้อมใช้งานและคุณภาพประสิทธิภาพในกลุ่มผู้ใช้ทั่วโลก ป้องกันการเลิกใช้งานของลูกค้าและปกป้องรายได้ทางธุรกิจ