บทความ 04
Concurrent Users, RPS, TPS และ Latency: อ่าน Load ของระบบให้เป็น
แยกจำนวนคนออกจากจำนวน request และ transaction พร้อมตัวอย่างแปลง GA Realtime เป็น workload model เบื้องต้นโดยไม่ตีความเกินข้อมูล
RPS
250
p95
780ms
TPS
38
สถานการณ์ตัวอย่าง
ลองเริ่มจากเหตุการณ์ที่คนทำงานพบจริง
มีผู้ใช้ 10,000 คน ไม่ได้แปลว่าระบบรับ 10,000 request พร้อมกัน
ผู้ใช้บางคนกำลังอ่าน บางคนค้นหา และมีเพียงบางส่วนกดบันทึกในวินาทีเดียวกัน การออกแบบระบบจากจำนวนสมาชิกทั้งหมดจึงอาจสูงหรือต่ำเกินจริง ต้องแปลงพฤติกรรมเป็น concurrent users, request rate และ business transaction ก่อน
ถ้าคุณไม่ได้ทำงานสายเทคนิค ให้เริ่มจากส่วนนี้
Concurrent Users, RPS, TPS และ Latency: อ่าน Load ของระบบให้เป็น
Concurrent users คือคนที่ active ในช่วงเดียวกัน ไม่ใช่สมาชิกทั้งหมด
RPS นับทุก request ส่วน TPS นับธุรกรรมที่มีความหมายทางธุรกิจ
Latency, error rate และ resource metric ต้องอ่านร่วมกับ throughput
ภาพขยายความแบบเคลื่อนไหว
ดูความสัมพันธ์ของแต่ละขั้น ก่อนลงรายละเอียด
เลือกแต่ละขั้นเพื่อดูว่าเกิดอะไรขึ้น ต้องตรวจข้อมูลใด และผลจากขั้นหนึ่งส่งต่อไปยังขั้นถัดไปอย่างไร
ขั้น 01 / 04
01 / แยกหน่วย
คน Request และ Transaction เป็นคนละมุมของระบบ
หนึ่ง transaction อาจเรียกหลาย API และแต่ละ API อาจ query database หลายครั้ง ตัวเลขจึงต่อกันเป็นชั้น การบอกเพียง concurrent users โดยไม่มีพฤติกรรม ไม่พอสำหรับกำหนด capacity
ประเด็นที่ต้องตรวจให้เห็นหลักฐาน
- Concurrent users: คนที่มีโอกาสกดใช้งานในช่วงเดียวกัน
- RPS: request ทั้งหมดต่อวินาที
- TPS: ธุรกรรมธุรกิจต่อวินาที
- Latency: เวลาตอบสนอง โดยควรดู p50, p95 และ p99
รายละเอียดเชิงลึก
ค่อย ๆ ดูทีละส่วนว่าเกิดอะไรขึ้น และควรเตรียมอย่างไร
เราเริ่มจากผลที่คนใช้งานหรือธุรกิจจะพบ แล้วจึงอธิบายว่าทีมเทคนิคต้องตรวจอะไร มีตัวอย่างแบบไหน และจุดใดไม่ควรปล่อยให้เดาเอง
01 / แยกหน่วย
01คน Request และ Transaction เป็นคนละมุมของระบบ
หนึ่ง transaction อาจเรียกหลาย API และแต่ละ API อาจ query database หลายครั้ง ตัวเลขจึงต่อกันเป็นชั้น การบอกเพียง concurrent users โดยไม่มีพฤติกรรม ไม่พอสำหรับกำหนด capacity
- Concurrent users: คนที่มีโอกาสกดใช้งานในช่วงเดียวกัน
- RPS: request ทั้งหมดต่อวินาที
- TPS: ธุรกรรมธุรกิจต่อวินาที
- Latency: เวลาตอบสนอง โดยควรดู p50, p95 และ p99
- Error rate: สัดส่วน request ที่ไม่สำเร็จ
02 / Workload model
02เริ่มจากพฤติกรรม แล้วค่อยแปลงเป็น RPS
กำหนดว่าผู้ใช้ active ทำ action กี่ครั้งในช่วงเวลาใด แต่ละ action สร้าง request กี่รายการ และช่วงพีคสูงกว่าปกติเท่าไร ตัวคูณเหล่านี้ควรมาจาก access log, analytics หรือการสังเกต ไม่ใช่ค่า default เดียวสำหรับทุกระบบ
ตัวอย่างคำนวณ
ผู้ใช้พร้อมกัน 500 คน
แต่ละคนสร้างเฉลี่ย 1.5 request ทุก 6 วินาที และเผื่อ peak multiplier 2 เท่า
Base RPS = 500 × 1.5 ÷ 6 = 125; Peak RPS = 125 × 2 = 250250 RPS เป็น target ตั้งต้นสำหรับออกแบบ test ไม่ใช่ผลยืนยันว่า production รองรับได้
03 / จาก GA สู่ Server
03GA Realtime เป็นจุดเริ่ม ไม่ใช่ค่า Concurrent โดยตรง
GA แสดงผู้ใช้ใน time window ขณะที่ server รับ request ทุกวินาที การแปลงต้องรู้ active duration, page behavior, background calls และสัดส่วนผู้ใช้ที่กำลังโต้ตอบจริง หลังได้ estimate แล้วต้องเทียบกับ access log และ metric จาก server/database
ระบบ SPA อาจยิง API หลายครั้งต่อ page view ส่วน background polling และ retry ทำให้ RPS สูงกว่าที่เห็นจาก screen interaction
04 / ข้อจำกัด
04RPS เท่ากัน ไม่ได้แปลว่าใช้ทรัพยากรเท่ากัน
Request อ่านข้อมูลจาก cache กับ request สร้างรายงานขนาดใหญ่มีต้นทุนต่างกันมาก ต้องแยก endpoint, payload, query count, external dependency และ cache hit rate ก่อนสรุป capacity
ก่อนนำไปใช้ ลองตรวจทีละข้อนี้
นิยาม active user
ระบุ action สำคัญ
นับ request ต่อ action
แยก business transaction
กำหนด peak multiplier จากข้อมูล
เทียบ estimate กับ log จริง
แหล่งอ้างอิง
ตัวอย่างในบทความช่วยให้เริ่มคุยกันได้ แต่ระบบแต่ละแห่งมีจำนวนผู้ใช้ ข้อมูล และข้อจำกัดไม่เหมือนกัน จึงควรตรวจจากระบบจริงอีกครั้งก่อนตัดสินใจ
- ผู้ตรวจทาน
- SIS Engineering
- ตรวจทานล่าสุด
- 2026-07-17
อ่านแล้วอยากรู้ว่าระบบของคุณควรเริ่มตรวจตรงไหน?
ลองใช้เครื่องมือประเมินเบื้องต้น หรือเล่าให้ทีม SIS ฟังว่าระบบทำอะไร ใครใช้งาน และตอนนี้กังวลเรื่องใด เราจะช่วยเรียงสิ่งที่ควรตรวจให้เป็นลำดับ