เทคโนโลยี

Performance Testing

เริ่มทำ Performance Testing

ปรับปรุงล่าสุด 29/10/2569
Performance Testing

เลือกสคริปต์ก่อน

ปกติคำแนะนำก็คือใช้ K6 กัน แต่ถ้าอยากเลือก C# ก็เลือก NBomber ส่วนช่วงนี้เราชอบ C# ก็เลือกใช้ NBomber

เราจะวัดอะไรบ้าง?

Metric ความหมาย สิ่งที่ต้องการ
Average เวลาตอบกลับเฉลี่ย ยิ่งน้อยยิ่งดี
p95 95% ของคำขอตอบกลับได้ภายในเวลานี้ ยิ่งน้อยยิ่งดี
Error Rate สัดส่วนคำขอที่ล้มเหลว ใกล้ 0%

RPS

Request per Second ต่อ 1 วินาที ยิงกี่ครั้ง เช่น

  • บอกว่า 1 RPS ยิงเป็นเวลา 30 วินาที ก็ต้องได้ 30 Request
  • 3 RPS ยิงเป็นเวลา 30 วินาที จะได้ 90 Request

สูตรคือ เอา จำนวน Request / ระยะเวลา

Throughput (Rate)

ปริมาณข้อมูลทั้งหมดที่ระบบ (Client และ Server) รับส่งผ่านเครือข่ายต่อหนึ่งวินาที เป็นผลรวมของ:

  • Request Data: ข้อมูลที่โปรแกรมทดสอบส่งไปหา Server (เช่น Header, Payload หรือ Body ที่ส่งไป)
  • Response Data: ข้อมูลที่ Server ตอบกลับมา (เช่น JSON, HTML, รูปภาพ หรือไฟล์ต่างๆ)

ทำไมค่านี้ถึงสำคัญในการ Performance Testing?

  • ใช้วัดขีดจำกัดของ Network Bandwidth: ช่วยให้รู้ว่าการทดสอบโหลดระดับนี้ ใช้ท่อส่งสัญญาณอินเทอร์เน็ต/เน็ตเวิร์กหนาแน่นแค่ไหน ป้องกันไม่ให้ Network Card ของเครื่องรันเทสต์หรือเครื่อง Server เต็ม (Bottleneck ที่เน็ตเวิร์ก)
  • ใช้คำนวณต้นทุนคลาวด์ (Cloud Cost): ระบบคลาวด์ส่วนใหญ่ (เช่น AWS, Azure) คิดเงินค่า Data Transfer (Outbound Traffic) ตามปริมาณข้อมูลที่ส่งออกไป ยิ่ง Throughput สูง ต้นทุนค่าเซิร์ฟเวอร์ก็ยิ่งสูงตาม
  • ตรวจสอบความผิดปกติของระบบ:
    • ถ้าจู่ๆ Throughput พุ่งสูงปรี๊ดผิดปกติ ทั้งที่จำนวนผู้ใช้งาน (Virtual Users) เท่าเดิม อาจแปลว่า Server ส่งข้อมูลขยะหรือข้อมูลส่วนเกิน (Over-fetching) กลับมาหา Client
    • หรือถ้า Throughput ตกลงเป็นศูนย์ แปลว่าระบบอาจจะล่มและหยุดตอบสนองไปแล้ว

แผนทดสอบรอบต่อไป

ระดับ RPS ระยะเวลา จำนวน Requests โดยประมาณ
รอบที่ 1 1 30 วินาที 30
รอบที่ 2 2 30 วินาที 60
รอบที่ 3 3 30 วินาที 90
รอบที่ 4 4 30 วินาที 120

แนะนำให้รัน แยกทีละรอบ และเพิ่มระดับเมื่อรอบก่อนหน้าไม่มี Error หรือสัญญาณว่า Server รับโหลดไม่ไหว

หลักการคือดูว่าเมื่อเพิ่ม RPS แล้วค่า p95 เพิ่มขึ้นมากแค่ไหน และเริ่มเกิด HTTP 429, 500, 502, 503 หรือ Timeout หรือไม่

ควรดูอะไรในรายงาน

Metric เกณฑ์เริ่มต้นสำหรับทดลอง
Average บันทึกเปรียบเทียบแต่ละ RPS
p95 เป้าหมายเบื้องต้นต่ำกว่า 1,000 ms
Error Rate 0%
RPS ทำได้ใกล้เคียงค่าที่ตั้ง
HTTP 429 / 5xx ไม่ควรเกิด

ค่า p95 ต่ำกว่า 1,000 ms เป็นเพียงเกณฑ์ทดลองที่ตั้งขึ้น ไม่ใช่มาตรฐานตายตัวของเว็บไซต์นี้ หาก Error เพิ่มขึ้นอย่างต่อเนื่องหรือเว็บเริ่มผิดปกติ ให้หยุดทดสอบทันที

จะรู้ได้ไงว่า ไม่ไหวแล้ว ผิดปรกติแล้ว

เราจะรู้ว่า Server เริ่มรับโหลดไม่ไหวจาก พฤติกรรมที่เปลี่ยนไปเมื่อเพิ่ม RPS ครับ ไม่ใช่ดูแค่ว่า Server ตอบกลับ HTTP 500 หรือไม่

ตัวอย่างเช่น เว็บไซต์อาจรับ 50 RPS ได้สบาย แต่เมื่อเพิ่มเป็น 100 RPS เวลา Response เพิ่มจาก 100 ms เป็น 2,000 ms แม้ไม่มี Error เลย แบบนี้ก็ถือว่าเริ่มมีปัญหาแล้ว

ตัวอย่างเมื่อเพิ่ม RPS ไปเรื่อย ๆ

Target RPS p95 Error Rate ประเมินเบื้องต้น
1 110 ms 0% ปกติ
5 115 ms 0% ปกติ
10 130 ms 0% ปกติ
20 160 ms 0% ปกติ
30 350 ms 0% เริ่มช้าลง
40 950 ms 1% ควรตรวจสอบ
50 2,100 ms 8% เกินเกณฑ์ตัวอย่าง

จะรู้ได้อย่างไรว่า Server รองรับสูงสุดกี่ RPS?

  1. วัด Baseline ที่โหลดต่ำก่อน
  2. เพิ่ม RPS ทีละระดับ
  3. ทดสอบแต่ละระดับนานประมาณ 1–3 นาที หลังจากการทดลองสั้น ๆ ผ่านแล้ว
  4. ตรวจ p95, Error Rate และ RPS ที่ตอบสำเร็จจริง
  5. ถ้าเริ่มไม่ผ่านเกณฑ์ ให้ลด RPS ลงแล้วทดสอบซ้ำ
  6. ทดสอบระดับที่ผ่านซ้ำหลายรอบเพื่อยืนยันความเสถียร
เขียนโดย KanexKane

นักเขียนโค้ด นักเก็บเรื่องราว และนักทดสอบ ชอบแบ่งปันสิ่งเล็ก ๆ ที่ทำให้วันธรรมดาพิเศษขึ้น

รู้จักกันอีกนิด →