TPS ไม่เท่ากับจำนวนคน: ความเข้าใจผิดที่ทำให้ระบบล่มทั้งที่ “ตัวเลขผ่าน”

ลองนึกภาพร้านกาแฟร้านหนึ่ง บาริสต้าฝีมือดีชงกาแฟได้ 1 แก้วใน 1 วินาทีพอดี ถ้าเราพูดว่า “ร้านนี้ทำกาแฟได้ 60 แก้วต่อนาที” มันก็ฟังดูน่าประทับใจ แต่คำถามที่สำคัญกว่าคือ — แล้วร้านนี้รับลูกค้าพร้อมกันได้กี่คน?

คำตอบอาจจะทำให้คุณตกใจ เพราะมันไม่ใช่ 60 คน และไม่ใช่ตัวเลขที่เดาได้ง่าย ๆ เลย

01TPS คืออะไร แล้วทำไมมันหลอกเรา

TPS ย่อมาจาก Transactions Per Second แปลตรงตัวว่า “จำนวนรายการที่ระบบประมวลผลได้ต่อวินาที” เวลาทีมพัฒนาบอกว่า “ระบบเรารับได้ 1,000 TPS” หลายคนจะเผลอแปลในใจทันทีว่า “อ๋อ รับคนได้พร้อมกัน 1,000 คนนั่นเอง”

นี่แหละคือจุดที่ความเข้าใจผิดเริ่มต้นขึ้น

TPS เป็นการวัด ปริมาณงานที่ไหลผ่านระบบ ในหนึ่งวินาที ไม่ใช่จำนวนคน ส่วน Concurrent Users คือ จำนวนคนที่กำลังใช้งานอยู่พร้อมกัน ในช่วงเวลาหนึ่ง สองสิ่งนี้เกี่ยวข้องกันก็จริง แต่มันไม่ใช่ตัวเลขเดียวกัน และความแตกต่างนี้แหละที่ทำให้ระบบหลายระบบล่ม ทั้งที่ผลทดสอบดู “ผ่าน” ทุกตัวเลข

02ตัวเลขจริงที่ทำให้หลายคนงง

ลองคิดเลขกันแบบง่าย ๆ สมมติว่าระบบของคุณรับได้ 1,000 TPS และผู้ใช้แต่ละคนกดทำรายการ 1 ครั้ง แล้วนั่งอ่านผลลัพธ์ คิดดู พิมพ์ข้อมูล ก่อนจะกดครั้งถัดไป รวมแล้วใช้เวลา “คิดและอ่าน” ประมาณ 10 วินาทีต่อหนึ่งการกระทำ

ถ้าผู้ใช้หนึ่งคนกดเพียง 1 ครั้งทุก ๆ 10 วินาที นั่นหมายความว่าคนหนึ่งคนสร้างโหลดแค่ 0.1 TPS เท่านั้น เอา 1,000 หารด้วย 0.1 ก็เท่ากับว่ามันรองรับคนได้พร้อมกันถึง 10,000 คน ไม่ใช่ 1,000 คนอย่างที่หลายคนเข้าใจ

แต่เดี๋ยวก่อน — มันไปทางกลับกันได้เหมือนกัน

ถ้าระบบของคุณเป็นแบบที่ผู้ใช้กดรัว ๆ ไม่มีหยุดพัก เช่น แอปเทรดหุ้นที่กดดูราคาทุกวินาที หรือเกมที่ส่งข้อมูลตลอดเวลา ผู้ใช้หนึ่งคนอาจสร้างโหลดถึง 2–3 TPS

ในกรณีนี้ ระบบที่รับได้ 1,000 TPS เท่ากัน อาจรองรับคนได้พร้อมกันแค่ 300–500 คน เท่านั้น

“ตัวเลข TPS เดียวกัน อาจหมายถึงคน 10,000 คน หรือ 400 คน ขึ้นอยู่กับว่าคนของคุณใช้งานแบบไหน”

ตัวแปรที่ทำให้ทุกอย่างเปลี่ยนไปคือสิ่งที่เรียกว่า Think Time หรือเวลาที่ผู้ใช้ “หยุดคิด” ระหว่างการกระทำแต่ละครั้ง คนจริงไม่ได้กดปุ่มเหมือนหุ่นยนต์ พวกเขาอ่าน เลื่อนหน้าจอ ลังเล เปลี่ยนใจ คุยโทรศัพท์ไปด้วย และนี่คือสิ่งที่การวัดแค่ TPS มองไม่เห็น

03ทำไมความเข้าใจผิดนี้ถึงอันตราย

ปัญหาคือ เวลาเราตั้งเป้าหมายผิด เราก็ทดสอบผิด และพอทดสอบผิด เราก็มั่นใจในสิ่งที่ไม่ควรมั่นใจ

หรือในทางกลับกัน ทีมที่บอกว่า “เราทดสอบแล้ว 1,000 TPS ผ่านสบาย รองรับ 1,000 คนได้แน่นอน” แล้วเปิดใช้งานจริง ปรากฏว่าวันนั้นมีคนเข้ามาแค่ 800 คน แต่เป็นคนประเภทที่กดรัว ๆ ระบบจึงล่มทั้งที่จำนวนคน “น้อยกว่า” ที่ทดสอบไว้เสียอีก

ทั้งสองกรณีเกิดจากรากเดียวกัน — การเอา “หน่วยของงาน” ไปปนกับ “หน่วยของคน”

04แล้วทำไมควรตั้งเป้าเป็น TPH

ทีนี้มาถึงประเด็นที่อยากชวนคิดจริง ๆ ทำไมหลายองค์กรที่ทำระบบมานานถึงเลือกตั้งเป้าหมายเป็น TPH — Transactions Per Hour หรือจำนวนรายการต่อชั่วโมง แทนที่จะเป็นต่อวินาที?

เหตุผลแรกคือ มันตรงกับวิธีที่ธุรกิจคิด ไม่มีฝ่ายการตลาดคนไหนบอกว่า “เราคาดว่าจะมีออเดอร์ 3 รายการต่อวินาที” แต่เขาจะบอกว่า “แคมเปญนี้น่าจะมีออเดอร์เข้ามาประมาณ 50,000 รายการในช่วงเช้าวันเปิดตัว” ตัวเลขแบบรายชั่วโมงคือภาษาที่ธุรกิจใช้สื่อสารกันจริง ๆ การตั้งเป้าเป็น TPH จึงเชื่อมโลกของวิศวกรเข้ากับโลกของธุรกิจได้โดยตรง

เหตุผลที่สองคือ มันบังคับให้เราคิดเรื่องการกระจายตัวของโหลด เมื่อคุณบอกว่า “ต้องรองรับ 360,000 รายการต่อชั่วโมง” คุณจะถูกบังคับให้ถามต่อทันทีว่า แล้วมันมาแบบไหน? มาเฉลี่ยเท่า ๆ กันทั้งชั่วโมง (เท่ากับ 100 TPS) หรือมากระจุกตัวในนาทีแรก ๆ (อาจพุ่งเป็น 1,000 TPS ในช่วงพีค) คำถามนี้สำคัญมาก เพราะระบบที่รับโหลดเฉลี่ยได้ อาจตายตอนพีคก็ได้

เส้นสีเทากับเส้นสีแดงในกราฟด้านบน “รวมแล้วเท่ากัน” คือ 360,000 รายการต่อชั่วโมงทั้งคู่ แต่เส้นเทาไหลเรียบที่ราว 100 TPS ตลอด ระบบสบายมาก ในขณะที่เส้นแดงพุ่งทะลุเพดานในนาทีแรก ๆ ตอนเปิดตัว แล้วค่อย ๆ ลดลง — และตรงจุดที่มันทะลุเส้นประสีดำนั่นแหละคือวินาทีที่ระบบล่ม ทั้งที่ “ตัวเลขต่อชั่วโมง” ผ่านสบาย ๆ

“TPS บอกว่าระบบเร็วแค่ไหนในวินาทีนั้น แต่ TPH บอกว่าระบบอยู่รอดได้ทั้งชั่วโมงหรือเปล่า”

เหตุผลที่สามคือ มันสะท้อนความเป็นจริงของระบบที่ต้องทำงานต่อเนื่อง ระบบหลายอย่างไม่ได้พังเพราะรับพีควินาทีเดียวไม่ไหว แต่พังเพราะต้องแบกโหลดสะสมไปเรื่อย ๆ เป็นชั่วโมง จนหน่วยความจำเต็ม จนคิวงานล้น จนฐานข้อมูลเริ่มช้าลง ปัญหาประเภทนี้จะโผล่มาก็ต่อเมื่อเราวัดในกรอบเวลาที่ยาวพอ และนั่นคือสิ่งที่ TPH มองเห็นแต่ TPS วินาทีเดียวมองไม่เห็น

05สรุปให้จำง่าย ๆ

ถ้าจะให้จำอะไรไปสักอย่างจากบทความนี้ ขอให้จำสามข้อนี้

การวัดที่ถูกต้องเริ่มจากการ “ถามคำถามที่ถูก” ก่อนเสมอ คำถามไม่ควรเป็น “ระบบเราทำได้กี่ TPS” แต่ควรเป็น “เราคาดว่าจะมีงานเข้ามากี่รายการต่อชั่วโมง มันจะกระจุกตัวตอนไหน และคนของเราใช้งานแบบไหน”

ตอบสามคำถามนี้ให้ได้ก่อน แล้วตัวเลข TPS ที่ถูกต้องจะตามมาเอง — ไม่ใช่ตัวเลขที่ดูสวยบนรายงาน แต่ตัวเลขที่ช่วยให้ระบบของคุณรอดในวันที่ลูกค้าเข้ามาจริง