ในการวัด Performance ของระบบ ที่เราสนใจเช่น response time หรือ latency เราจะดู distribution ของ metric ที่ต้องการวัด
ทำไมต้องดู Distribution?
เหตุผลคือ Response time ของแต่ละ request มักจะไม่เท่ากัน ต่อให้เป็น request เดียวกันก็ตาม เช่นบางครั้งใช้เวลา 10ms บ้าง 50ms บ้าง หรือ 200ms บ้าง ซึ่งขึ้นอยู่กับหลาย factor เช่น garbage collection, network jitter, หรือ cache miss ดังนั้นถ้าบอกแค่ตัวเลขเดียว เราจะเสีย context ที่สำคัญไป
ทบทวนกันหน่อยว่า Average และ Median คืออะไร?
Average (หรือ Mean) คือ ค่าเฉลี่ยของ sample หารด้วยจำนวนของ sample แต่ Average จะมีปัญหาคือ จะถูก outlier ดึงค่า Average ให้สูงขึ้นได้ง่ายมาก
ตัวอย่าง response times = [10, 12, 11, 13, 500] ms จะได้ Average = 109.2 ms ซึ่งไม่ได้ represent user ส่วนใหญ่เลย
เราเลยจำเป็นต้องดู statistics อื่นๆ ด้วย นั่นคือ Median หรือ p50
Median (p50) หมายความว่า ถ้า sort request ทั้งหมดตาม response time แล้วเอาตัวกลาง คือ 50% ของ user ได้เร็วกว่านี้ และอีก 50% ได้ช้ากว่านี้
Median จึงเหมาะกว่ามากในการบอกว่า “user ทั่วไปมีประสบการณ์เป็นยังไง”
Percentiles และ Tail Latency
Percentile คือการถามว่า “ที่ rank นี้ในการ sort ทั้งหมด ตัวเลขคืออะไร”
| Percentile | ความหมาย |
|---|---|
| p50 | 50% ของ request เร็วกว่าหรือเท่ากับค่านี้ |
| p95 | 95% ของ request เร็วกว่าหรือเท่ากับค่านี้ (มี 5% ที่ช้ากว่า) |
| p99 | 99% ของ request เร็วกว่าหรือเท่ากับค่านี้ (มี 1% ที่ช้ากว่า) |
| p999 | 99.9% ของ request เร็วกว่าหรือเท่ากับค่านี้ (มี 0.1% ที่ช้ากว่า) |
ตัวเลขที่ p95 ขึ้นไปเรียกว่า tail latency ซึ่งมักสูงกว่า median มากผิดปกติ
ทำไม Tail Latency ถึงสำคัญ?
1. User ที่โดน tail latency มักเป็น user ที่สำคัญที่สุด
Amazon เคยเจอ insight ที่ว่า user ที่ request ช้าที่สุดมักเป็นคนที่มีของในตะกร้ามากที่สุด เพราะ server ต้องทำงานมากกว่า นั่นแปลว่า best customer กลับได้ experience แย่ที่สุด
2. Fan-out effect ทำให้ปัญหาขยายตัว
ถ้า service นึง call backend หลายตัวแบบ parallel โอกาสที่ request นั้นจะโดน slow backend อย่างน้อย 1 ตัว คำนวณได้จาก:
P(โดนช้าอย่างน้อย 1 ตัว) = 1 - (1 - p)^n
โดย p คือโอกาสที่แต่ละ backend จะช้า และ n คือจำนวน backend ที่ call
ตัวอย่าง ถ้าแต่ละ backend มีโอกาส 1% ที่จะช้า:
- call 100 ตัว →
1 - 0.99^100 ≈ 63% - call 500 ตัว →
1 - 0.99^500 ≈ 99.3%
นั่นแปลว่า ปัญหา p99 ของ individual service สามารถกลายเป็นปัญหา p50 (หรือแย่กว่า) ของ end-to-end request ได้ง่ายๆ
ตัวอย่างการตั้ง SLO/SLA
ในทางปฏิบัติ engineering team มักตั้ง target แบบนี้:
- p50 < 50ms
- p95 < 200ms
- p99 < 1s
แทนที่จะบอกแค่ “average < 100ms” เพราะ average ไม่บอกอะไรเกี่ยวกับ worst case เลย
สรุป
ไม่ควรใช้ Average เป็น baseline เพราะค่าเฉลี่ยจะถูกดึงได้ง่ายจาก outlier ให้ใช้ median เป็น baseline แทน และดู higher percentiles เพื่อเข้าใจว่า user ที่โชคร้ายที่สุดเจออะไร การ optimize โดยไม่ดู tail latency อาจทำให้เราคิดว่าระบบมันทำงานได้ดีกว่าความเป็นจริง