LOAD TEST / STRESS TEST

แอปพลิเคชันที่รับมือผู้ใช้สิบคนได้สบาย อาจล้มทั้งระบบตอนเจอผู้ใช้หนึ่งหมื่นคนพร้อมกัน โดยที่โค้ดไม่ต้องมีอะไรผิดเลย connection pool ที่ตั้งขนาดไว้เท่ากับ traffic ตอน develop, query ที่เคยเร็วตอนตารางยังเล็ก, cache ที่ไม่เคยถูกสั่งให้ evict อะไรออกมาก่อน ปัญหาพวกนี้มองไม่เห็นในการทดสอบ functional และในการใช้งานประจำวัน จนกระทั่งวันเปิดตัว แคมเปญการตลาด หรือแค่เช้าวันจันทร์ธรรมดา ที่โยน load จริงแบบ concurrent เข้ามาพร้อมกัน ถึงตอนนั้นต้นทุนก็วัดกันเป็นธุรกรรมที่หายไป session ที่ถูกทิ้งกลางคัน และผู้ใช้ที่เงียบ ๆ ตัดสินใจไม่กลับมาอีก ส่วน response time ที่ช้าก็สร้างความเสียหายแบบเดียวกันในเวอร์ชันสโลว์โมชัน ระบบยังอยู่ แต่ทุกการโต้ตอบก็กัดกร่อนความเชื่อใจไปทีละนิด

load testing กับ stress testing ตอบคำถามที่การทดสอบ functional ตอบไม่ได้ ระบบนี้รองรับ concurrent users ได้จริงกี่คน ประสิทธิภาพเริ่มตกที่ตรงไหน อะไรพังก่อนเมื่อความต้องการเกินกำลัง และระบบฟื้นกลับมาได้สะอาดหมดจดหลังจากนั้นไหม เราจำลองพฤติกรรมผู้ใช้จริงในสเกลใหญ่ วัดว่าระบบตอบสนองยังไง แล้วเปลี่ยนผลลัพธ์ให้เป็น finding ที่ทีมวิศวกรของคุณเอาไปลงมือแก้ได้ ไม่ใช่กำแพงกราฟกองโต แต่เป็น bottleneck ที่ระบุชื่อได้ชัดพร้อมคำแนะนำแนบมาด้วย

สิ่งที่เราทดสอบ

คำถามด้านประสิทธิภาพที่ต่างกัน ต้องออกแบบการทดสอบต่างกัน งานหนึ่งมักผสมหลายแบบต่อไปนี้ เลือกตามเป้าหมายของคุณตอนวางแผน

• Load Testing — วัดว่าระบบทำงานยังไงภายใต้สภาพปกติและ peak ที่คาดไว้ เราจำลอง concurrent users จำนวนมากตลอดช่วงเวลาที่กำหนด เดินตามสถานการณ์สมจริง ไม่ใช่กระหน่ำยิง endpoint เดียว แล้วบันทึก response time, throughput และ error rate ขณะที่ load ค้างอยู่ ตรงนี้ก็บอกได้ว่าระบบทำได้ตามเป้าประสิทธิภาพที่ระดับ traffic ที่คุณคาดว่าจะเจอจริงหรือเปล่า
• Stress Testing — ดัน load ขึ้นทีละขั้น เกิน peak ที่คาดไว้ ไปจนระบบล้มหรือเริ่มไม่เสถียร เป้าหมายคือหา breaking point ว่าระบบรับได้สูงสุดแค่ไหน ชิ้นส่วนไหนยอมแพ้ก่อน และล้มออกมาในรูปแบบไหน จะค่อย ๆ degrade, error ลามเป็นลูกโซ่ หรือ crash ทั้งระบบ พอรู้เพดานนี้ การวางแผน capacity ก็เปลี่ยนจากการเดา เป็นการคำนวณ
• Endurance / Soak Testing — คง load ระดับปกติไว้ยาว ๆ อย่างน้อย 8 ชั่วโมง เพื่อดึงปัญหาที่โผล่เฉพาะเมื่อเวลาผ่านไปออกมา memory leak, connection pool ที่ค่อย ๆ หมด, log ที่เขียนจนดิสก์เต็ม, ทรัพยากรที่ค่อย ๆ ร่อยหรอ ปัญหาพวกนี้ผ่านการทดสอบสั้น ๆ ไปได้แบบไม่ทิ้งร่องรอย soak test ก็คือวิธีจับมันให้ได้ก่อนที่มันจะล้ม production ตอนตีสาม
• Spike Testing — ประเมินว่าระบบรับมือการพุ่งขึ้นของผู้ใช้แบบฉับพลันยังไง ทั้งจังหวะ flash sale, โพสต์ที่กลายเป็นไวรัล, การแจ้งเตือนที่ยิงหาลูกค้าทุกคนพร้อมกัน และที่สำคัญไม่แพ้กัน คือมันทำตัวยังไงตอนคลื่นนั้นซาลง ระบบที่รอด spike มาได้แต่ไม่เคยกลับสู่ปกติ ก็ถือว่าสอบตกอยู่ดี

วิธีการทำงานของเรา

ทุกงานเดินผ่านเฟสเดียวกันเสมอ คุณเลยรู้ตลอดว่าโปรเจกต์อยู่ตรงไหน และจะได้อะไรต่อไป

1. วางแผน — เรากำหนดเป้าหมายร่วมกับคุณ ทดสอบแบบไหนบ้าง คำว่า "ดี" หน้าตาเป็นยังไง (response time เป้าหมาย, error rate ที่ยอมรับได้, จำนวน concurrent users ที่ต้องรองรับ) และ user journey ไหนสำคัญที่สุด จากนั้นก็สร้างสถานการณ์และโปรไฟล์ load ที่สะท้อนพฤติกรรมผู้ใช้จริง ทั้งสัดส่วนการเลือกดู ค้นหา และทำธุรกรรม ไม่ใช่ worst case ปลอม ๆ ที่พิสูจน์อะไรไม่ได้
2. ดำเนินการ — เรารันการทดสอบที่ตกลงกันด้วยเครื่องมือ load testing มาตรฐานอุตสาหกรรม สร้าง load ใส่ environment เป้าหมาย พร้อมเฝ้าดูพฤติกรรมระบบตลอดทาง ตารางเวลาและการประสานงานทำร่วมกับทีมคุณ เพื่อไม่ให้ stress test ที่ตั้งใจทำ ถูกเข้าใจผิดว่าเป็น incident จริง
3. วิเคราะห์ — metric ดิบกลายเป็น finding bottleneck อยู่ตรงไหน response time เปลี่ยนยังไงเมื่อ load ไต่ขึ้น ทรัพยากรไหน — CPU, memory, database connection, network — ชนขีดจำกัดก่อน และระบบเลิกทำได้ตามเป้าที่จุดไหน ทุก finding มาพร้อมคำแนะนำ ไม่ใช่แค่ตัวเลข
4. Retest — หลังทีมคุณแก้เสร็จ เรารันการทดสอบที่เกี่ยวข้องซ้ำภายใต้เงื่อนไขเดิม เพื่อยืนยันว่าการปรับปรุงเกิดผลจริงและวัดได้ เป็นวินัย before-and-after แบบเดียวกับที่เราใช้กับทุกงานประเมินที่ส่งมอบ

สิ่งที่คุณจะได้รับ

รายงานทุกฉบับมีอย่างน้อยสิ่งเหล่านี้

• Executive summary — ภาพ capacity และความเสี่ยงในภาษาธุรกิจ เหมาะให้ผู้บริหารอ่าน ระบบรับได้แค่ไหนวันนี้ และเพดานอยู่ตรงไหน
• รายงานประสิทธิภาพแบบละเอียด — throughput, response time ที่แต่ละระดับ load, error rate และ resource utilisation ตลอดรอบการทดสอบ พร้อมบันทึกการออกแบบการทดสอบไว้ให้ผลลัพธ์ทำซ้ำได้
• Bottleneck และ breaking point — ชิ้นส่วนที่จำกัดประสิทธิภาพจริง ๆ ระดับ load ที่ทำให้ระบบเริ่มไม่เสถียร และรูปแบบการล้มเมื่อมันล้ม
• คำแนะนำการ optimise — แนวทางปรับปรุงที่ทำได้จริงทั้งฝั่ง hardware, software และ configuration จุดไหนควร scale out จุดไหน tune แล้วคุ้มกว่า และแก้ตรงไหนได้ capacity มากที่สุดด้วยแรงน้อยที่สุด

การออกแบบการทดสอบ การดำเนินการ การวิเคราะห์ประสิทธิภาพ และคำแนะนำการ optimise เป็นส่วนหนึ่งของงานทั้งหมด คุณได้รับบริการ ไม่ใช่แค่ผลลัพธ์ดิบจากเครื่องมือ

ความเชี่ยวชาญของทีม

งานทดสอบประสิทธิภาพที่ Incognito Lab รันโดยทีมสายวิศวกรรมชุดเดียวกับที่ทำงานประเมินความปลอดภัยของเรา คนที่ชินกับการติดตั้งเครื่องมือวัดผลระบบ อ่านมันตอนอยู่ใต้แรงกดดัน และรายงานสิ่งที่เจอออกมาอย่างเที่ยงตรง วินัยเดียวกันหมด วิธีการที่ทำซ้ำได้ ผลลัพธ์ที่ตรวจสอบได้ และ finding ที่วิศวกรของคุณเอาไปลงมือต่อได้โดยไม่ต้องเดา ดูใบรับรองที่ทีมถือ

เมื่อไหร่ควรทำ

มีสามสถานการณ์ที่คุ้มจะทดสอบประสิทธิภาพเสมอ

• ก่อนเปิดตัวหรือแคมเปญใหญ่ — ตอนที่คุณรู้ว่า traffic กำลังมา และอยากมั่นใจว่าระบบจะรับไหว โดยยังมีเวลาเหลือพอจะแก้สิ่งที่ไม่ไหว
• หลังเปลี่ยนสถาปัตยกรรมครั้งใหญ่ — ย้ายระบบ เปลี่ยน database ใหม่ หรือ re-platform บริการ ผลทดสอบเก่าใช้ไม่ได้แล้ว และสมมติฐานที่ยกมาจากสถาปัตยกรรมเดิม ก็คือจุดที่เซอร์ไพรส์ชอบซ่อนตัว
• เพื่อวาง baseline ของ capacity — พอรู้เพดานปัจจุบัน การตัดสินใจเรื่อง scaling และงบ infrastructure ก็กลายเป็นทางเลือกที่มีข้อมูล ไม่ใช่การประเมินลอย ๆ และได้จุดอ้างอิงไว้วัดทุกการเปลี่ยนแปลงในอนาคต

ถ้าสถานการณ์ใดตรงกับที่คุณเป็นอยู่ การพูดคุยวางแผนก็ใช้เวลาไม่นาน บอกเราว่าระบบทำอะไร และคุณคาดหวังให้มันทนอะไรได้บ้าง แล้วเราจะออกแบบการทดสอบรอบตัวมันให้