📊 บทความ ⏱ อ่าน ~8 นาที

ทำไม Average Response Time
ถึงโกหกคุณทุกครั้ง

99 Request ตอบ 100ms แต่มี 1 Request ตอบ 10 วินาที — Average = 199ms ดูดีมาก แต่ User 1% ต้องรอถึง 10 วินาที ถ้าดูแค่ Average คุณจะพลาด Bottleneck ที่แท้จริง บทความนี้อธิบาย Metrics ที่ควรดูจริงๆ พร้อม Threshold มาตรฐาน แยกตามประเภทระบบ ตั้งแต่ E-commerce ไปจนถึง FinTech และ Healthcare

📌

Metrics ที่ดีต้องมาจาก Business Requirement

ก่อนทำ Performance Test ต้องกำหนด Acceptance Criteria จาก SLA ให้ชัดเจน เช่น "p95 Response Time < 2 วินาที ที่ 1,000 Concurrent Users และ Error Rate < 1%" จากนั้นใช้ Metrics เหล่านี้ในการ Pass/Fail Test

Key Metrics

⏱️ Response Time

⏱️

เวลาที่ระบบใช้ในการตอบสนองต่อ Request หนึ่งครั้ง นับตั้งแต่ Client ส่ง Request จนได้รับ Response ครบ รายงานในรูปแบบ Average, Median (p50), p90, p95, p99

Industry Standard Thresholds

ยอดเยี่ยม (p95) < 500ms

ยอมรับได้ (p95) < 2,000ms

ต้องปรับปรุง (p95) > 3,000ms

🚀 Throughput (TPS/RPS)

🚀

จำนวน Transaction หรือ Request ที่ระบบประมวลผลได้ต่อวินาที (TPS = Transactions Per Second, RPS = Requests Per Second) ยิ่งสูงยิ่งดี แต่ต้องดูควบคู่กับ Error Rate

วิธีคำนวณ TPS เป้าหมาย

Peak Users 1,000 users

Think Time 2 seconds

Target TPS = 1000 / 2 = 500

❌ Error Rate

❌

เปอร์เซ็นต์ของ Request ที่ได้รับ Error Response (HTTP 4xx/5xx) หรือ Timeout เทียบกับ Request ทั้งหมด เป็น Metric ที่สำคัญที่สุดในการบอกว่าระบบ "ล้มเหลว"

Threshold ที่ยอมรับได้

ยอดเยี่ยม < 0.1%

ยอมรับได้ < 1%

ล้มเหลว > 5%

😊 Apdex Score

😊

Application Performance Index — คะแนน 0–1 ที่รวม Response Time และ User Satisfaction เป็นตัวเลขเดียว คำนวณจาก Satisfied + Tolerating/2 หารด้วย Total Samples

Apdex Score Meaning

Excellent 0.94 – 1.0

Good 0.85 – 0.94

Fair 0.70 – 0.85

Poor / Unacceptable < 0.70

👥 Concurrent Users

👥

จำนวน User ที่ใช้งานระบบพร้อมกันในเวลาเดียวกัน แตกต่างจาก Active Users ที่เพิ่งเข้ามา คำนวณด้วย Little's Law: N = λ × W

Little's Law

N (Concurrent) = λ × W

λ (Arrival Rate) requests/sec

W (Response Time) seconds

💻 Resource Utilization

💻

การใช้งาน CPU, Memory, Network I/O และ Disk I/O ของ Server ระหว่าง Test ถ้า CPU สูงเกินไปอาจหมายถึง Code ไม่มีประสิทธิภาพ ถ้า Memory เพิ่มเรื่อยๆ อาจมี Memory Leak

Resource Thresholds (Production)

CPU (Sustained) < 70%

Memory < 80%

Network I/O < 70% bandwidth

Percentiles — ทำไมต้องดู p95 ไม่ใช่ Average?

⚠️

Average Response Time ทำให้เราเข้าใจผิด!

ถ้ามี 99 Request ที่ Response 100ms และ 1 Request ที่ Response 10,000ms Average = 199ms — ดูดีมาก แต่ความจริงคือ User 1% ต้องรอ 10 วินาที!

p50

Median

50% ของ Request เร็วกว่าค่านี้ ใช้แทน Average ได้ดีกว่า

p95

95th Percentile

95% ของ User ได้ Response เร็วกว่าค่านี้ — มาตรฐานที่ใช้กันมากที่สุด

p99

99th Percentile

Worst-case สำหรับ User ส่วนใหญ่ ใช้สำหรับ Critical System ที่ยอมให้ช้าไม่ได้

Apdex — วิธีคำนวณ

Formula — Apdex Score

── กำหนด T (Threshold) = 2 วินาที ────────────────────────────

Satisfied  : Response Time ≤ T         (≤ 2s)
Tolerating : Response Time ≤ 4T        (2s < t ≤ 8s)
Frustrated : Response Time > 4T        (> 8s)

── สูตร ────────────────────────────────────────────────────────

          Satisfied + (Tolerating / 2)
Apdex = ──────────────────────────────
                 Total Samples

── ตัวอย่าง ────────────────────────────────────────────────────
Satisfied  = 800  requests
Tolerating = 150  requests
Frustrated = 50   requests
Total      = 1000 requests

          800 + (150 / 2)       875
Apdex = ─────────────────── = ───── = 0.875  (Good ✓)
               1000             1000

SLA Thresholds ตาม Industry