Performance Testing: ปรับระบบให้พร้อม ก่อนเจอผู้ใช้งานจริง

“อย่าให้ระบบล่มในวันจริง เพราะคุณไม่เคยทดสอบมันในวันซ้อม”

Performance Testing คืออะไร?

Performance Testing คือกระบวนการทดสอบความสามารถของระบบในการตอบสนองภายใต้เงื่อนไขการใช้งานต่าง ๆ ไม่ว่าจะเป็นการใช้งานปกติ การใช้งานหนัก หรือการใช้งานต่อเนื่องเป็นเวลานาน จุดประสงค์หลักคือการค้นหาขีดจำกัดของระบบ และป้องกันปัญหาที่อาจเกิดขึ้นเมื่อเปิดใช้งานจริง เช่น ระบบล่ม หน่วง หรือมี Bug ที่ไม่เจอจาก Functional Test

ทำไมต้องทำ Performance Testing?

ลดความเสี่ยงระบบล่ม เมื่อมีผู้ใช้งานจำนวนมากพร้อมกัน
เพิ่มประสิทธิภาพของโค้ดและโครงสร้างระบบ
ประเมินความคุ้มค่าด้านทรัพยากร เช่น ต้องใช้เซิร์ฟเวอร์ขนาดเท่าไหร่จึงจะพอ?
ลดต้นทุน Server / Cloud จากการ Optimize ตามผลที่ได้
ยกระดับความพึงพอใจของผู้ใช้ ด้วย Response Time ที่สม่ำเสมอ

คำถามคลาสสิก: “พี่อยากลด Cost ของ Server ลดได้ไหม?” → Performance Test จะให้คำตอบ

ควรทำ Performance Test เมื่อไร?

ก่อน Launch โปรเจกต์จริง หรือหลัง Dev เสร็จในระดับ UAT
ก่อนช่วง Traffic พุ่ง เช่น วันโปร ฯ / โฆษณา / เปิดระบบ
เมื่อมีการเปลี่ยนแปลง Code หรือ Infrastructure สำคัญ

ประเภทของ Performance Test

ประเภท	จุดประสงค์
Load Testing	ทดสอบระบบเมื่อมีผู้ใช้งานในระดับปกติ
Stress Testing	ทดสอบเมื่อมีโหลดมากกว่าปกติ เพื่อดูจุดที่ระบบพัง
Spike Testing	ทดสอบโหลดที่เพิ่มขึ้นแบบฉับพลัน เช่น เปิดจองตั๋ว
Endurance Testing	ทดสอบการทำงานต่อเนื่องระยะยาว เช่น 8 ชม.ขึ้นไป

เครื่องมือยอดนิยม เช่น K6 ที่สามารถรันสคริปต์ด้วย JavaScript และเก็บผลวัดค่าต่าง ๆ ได้

สิ่งที่ต้องเตรียมก่อน Performance Test

Application Code ต้องพร้อม
มี Environment สำหรับ Deploy และทดสอบ (Staging, Pre-Prod)
รู้สเปคของ Server และ Container Resource
มีสคริปต์สำหรับ Load เช่น test-basic.js, test-queue.js
Monitoring พร้อม เช่น CPU, Memory, Disk, Network

ตัวอย่าง Script ทดสอบ (K6)

import http from 'k6/http';
import { sleep } from 'k6';

export default function () {
  http.get('https://example.com/api/endpoint');
  sleep(1);
}

สามารถเพิ่ม options เพื่อจำลอง Virtual Users และ Ramp-Up Time ได้ เช่น:

export let options = {
  vus: 100,
  duration: '30s',
};

กรณีที่ระบบไม่ไหว ทำไงดี?

หากพบว่า Response Time สูง หรือระบบไม่เสถียร:

ใช้ Message Queue เพื่อหน่วงคำสั่งไว้รอประมวลผล
เพิ่ม Endpoint ใหม่เพื่อแยกโหลด เช่น register-queue
แยก Service ออกมา (Microservices)
ปรับการ Scale ระบบแบบ Auto / Manual

สรุป: ทำ Performance Testing แล้วต้อง “ใช้ผลลัพธ์” ด้วย

การทำ Performance Test ไม่ใช่แค่การทดสอบให้ครบ แต่คือการนำผลที่ได้ไป วิเคราะห์ ปรับปรุง และตัดสินใจ ว่าจะเพิ่มทรัพยากร หรือ Optimize จุดใด

“สุดท้าย K6 หรือ Tools ไหน ๆ ก็เป็นแค่เครื่องมือ ถ้าไม่เอาผลไปปรับปรุงระบบ มันก็ไร้ประโยชน์”

บทความนี้เผยแพร่ในกิจกรรม Knowledge Sharing โดยบริษัท ยีราฟ จำกัด เพื่อส่งเสริมความรู้ด้าน Software Engineering และ DevOps แก่ทีมภายใน