Load Testing: ซ้อมรับลูกค้าหนึ่งหมื่นคน ก่อนวันที่พวกเขามาจริง

ระบบที่ลื่นตอนคนใช้ร้อยคน อาจล่มสนิทตอนหมื่นคนเข้าพร้อมกันในนาทีเปิดแคมเปญ Load Testing คือการจำลองผู้ใช้จำนวนมากยิงเข้าระบบก่อนวันจริง เพื่อหาจุดที่จะพังตอนที่ยังแก้ทัน
ระบบส่วนใหญ่ถูกทดสอบว่าทำงานถูกต้องไหม แต่แทบไม่เคยถูกถามว่ารับได้กี่คน ความจริงที่เจ็บปวดคือความถูกต้องกับความทนทานเป็นคนละเรื่อง ระบบที่ทุกฟีเจอร์ทำงานสมบูรณ์ตอนมีผู้ใช้ร้อยคน อาจช้าลงจนใช้ไม่ได้ตอนพันคน และล่มสนิทตอนหมื่นคนเข้าพร้อมกันในนาทีแรกของแคมเปญที่ทุ่มงบโฆษณาไปมหาศาล Load Testing คือการซ้อมสถานการณ์นั้นล่วงหน้า ใช้เครื่องมือจำลองผู้ใช้เสมือนจำนวนมากเข้าใช้งานระบบพร้อมกัน แล้ววัดว่าอะไรเกิดขึ้นจริงที่ระดับไหน
หาเพดานให้เจอ ก่อนลูกค้าจะเจอแทน
คุณค่าของการทดสอบไม่ใช่ตัวเลขว่ารับได้กี่คน แต่คือการได้เห็นว่าอะไรพังก่อน ทุกระบบมีคอขวดเสมอ บางระบบตายที่ฐานข้อมูลเพราะจำนวนการเชื่อมต่อเต็ม บางระบบตายที่จุดชำระเงินเพราะรอบริการภายนอก การทดสอบทำให้รู้ว่าคอขวดของเราอยู่ตรงไหนและเพดานอยู่ที่เท่าไร จากนั้นการเตรียมตัวจึงเป็นเรื่องของข้อมูล ไม่ใช่ความหวัง สิ่งสำคัญคือต้องซ้อมด้วยพฤติกรรมที่สมจริง ผู้ใช้จริงไม่ได้กดหน้าแรกอย่างเดียว แต่ค้นสินค้า ใส่ตะกร้า และจ่ายเงิน และควรซ้อมแบบพุ่งพรวด เพราะหมื่นคนที่ทยอยมาในหนึ่งชั่วโมงกับหมื่นคนในนาทีเดียว ให้ผลต่างกันคนละโลก
- ซ้อมด้วยพฤติกรรมจริง ค้นหา ใส่ตะกร้า จ่ายเงิน ไม่ใช่แค่เปิดหน้าแรก
- ทดสอบแบบพุ่งพรวดเท่าวันจริง ไม่ใช่ทยอยเข้าแบบวันปกติ
- รู้เพดานและคอขวดก่อนวันงาน แล้ววางแผนขยายหรือรับมือไว้ล่วงหน้า
Load Testing คือความแตกต่างระหว่างการหวังว่าระบบจะไหวกับการรู้ว่ามันไหว สำหรับธุรกิจที่มีวันสำคัญในปฏิทิน วันเปิดตัวสินค้า มหกรรมลดราคา หรือช่วงพีคตามฤดูกาล การซ้อมรับโหลดควรเป็นรายการบังคับในการเตรียมงาน เช่นเดียวกับที่ร้านอาหารไม่รับจองสองร้อยโต๊ะโดยไม่เคยลองทำอาหารพร้อมกันเกินยี่สิบจาน คำถามเดียวที่ผู้บริหารต้องถามทีมก่อนแคมเปญใหญ่คือ เราซ้อมที่ตัวเลขเท่าไร และวันจริงคาดว่าจะมาเท่าไร
บริการที่เกี่ยวข้อง
รับพัฒนาเว็บแอปพลิเคชัน
สร้างเว็บแอปที่รองรับการเติบโตและเชื่อมกับระบบอื่นได้
WhaleScope
ดูโครงสร้างตลาดของทุกหมวดธุรกิจไทย บน WhaleScope
รายชื่อบริษัท ผู้เล่นรายใหญ่ และอัตราคงอยู่ของแต่ละหมวด — จากข้อมูลจดทะเบียน 2 ล้านนิติบุคคล
อ่านต่อ

Read Replica: แยกงานอ่านออกจากงานเขียน เพื่อให้ระบบไหว
ระบบส่วนใหญ่อ่านข้อมูลบ่อยกว่าเขียนมาก เมื่อฐานข้อมูลเดียวรับทั้งสองไม่ไหว Read Replica คือการทำสำเนาไว้รับงานอ่าน ช่วยให้รายงานและหน้าเว็บเร็วขึ้นโดยไม่กระทบงานเขียน

Database Index: ทำไมระบบช้าลงเมื่อข้อมูลโต และแก้ได้อย่างไร
ระบบที่เคยเร็วตอนข้อมูลน้อย เริ่มอืดเมื่อข้อมูลโตขึ้น สาเหตุยอดฮิตคือการค้นหาที่ไม่มี Index เข้าใจว่า Index ช่วยอย่างไร และทำไมใส่มากเกินก็เป็นปัญหา

Connection Pooling: จัดการการเชื่อมต่อฐานข้อมูลให้ไม่ล้น
ทุกการเชื่อมต่อฐานข้อมูลมีต้นทุน ถ้าเปิดใหม่ทุกคำขอ ระบบจะช้าและล้มเมื่อคนเยอะ Connection Pooling คือการใช้การเชื่อมต่อซ้ำจากสระกลาง ทำให้เร็วขึ้นและทนโหลดได้มากขึ้น

Cache ผิดที่ ทำให้ข้อมูลเก่าค้าง: เข้าใจ Cache Invalidation
Cache ทำให้ระบบเร็วขึ้น แต่ถ้าไม่ล้างให้ถูกจังหวะ ลูกค้าอาจเห็นราคาเก่า สต็อกผิด หรือโปรที่หมดไปแล้ว เข้าใจว่าเมื่อไรควร Cache และเมื่อไรต้องล้าง คือหัวใจของระบบที่ทั้งเร็วและถูกต้อง
