DEV Community

Cover image for การทดสอบประสิทธิภาพ: ประเภท, ตัวชี้วัด และวิธีการทำงาน
Thanawat Wongchai
Thanawat Wongchai

Posted on • Originally published at apidog.com

การทดสอบประสิทธิภาพ: ประเภท, ตัวชี้วัด และวิธีการทำงาน

ซอฟต์แวร์ที่ “ทำงานถูกต้อง” ไม่ได้แปลว่า “ทำงานได้ดีเมื่อมีผู้ใช้จริงจำนวนมาก” ฟีเจอร์อาจผ่าน functional test ทั้งหมด แต่ล้มเหลวทันทีเมื่อเจอโหลดจริง การทดสอบประสิทธิภาพจึงเป็นวิธีวัดว่าระบบตอบสนองอย่างไรภายใต้ภาระงาน ไม่ใช่แค่ว่าฟีเจอร์ทำงานถูกต้องหรือไม่

ลองใช้ Apidog วันนี้

คู่มือนี้สรุปแนวทางการทำ performance testing แบบนำไปใช้ได้จริง: ควรทดสอบอะไร วัดเมตริกไหน วางไว้ตรงไหนใน CI/CD และควรหลีกเลี่ยงข้อผิดพลาดใดบ้าง

การทดสอบประสิทธิภาพคืออะไร

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

แทนที่จะถามว่า:

ฟีเจอร์นี้ใช้งานได้หรือไม่?

ให้ถามว่า:

ฟีเจอร์นี้ตอบสนองเร็วแค่ไหน รองรับผู้ใช้ได้เท่าไร และล้มเหลวอย่างไรเมื่อถึงขีดจำกัด?

ตัวอย่างเช่น endpoint สำหรับ login อาจคืน token ถูกต้องทุกครั้ง แต่ใช้เวลา 4 วินาทีเมื่อมีผู้ใช้พร้อมกันจำนวนมาก Functional test จะผ่าน แต่ผู้ใช้จริงอาจออกจากระบบไปแล้ว Performance test คือสิ่งที่เปิดเผยปัญหาแบบนี้

ผลลัพธ์ที่ดีไม่ควรเป็นแค่ “ผ่าน/ไม่ผ่าน” แต่ควรตอบได้ว่า:

  • ที่ concurrency ระดับหนึ่ง ระบบตอบสนองกี่มิลลิวินาที
  • throughput สูงสุดอยู่ที่เท่าไร
  • error rate เริ่มเพิ่มเมื่อใด
  • คอขวดอยู่ที่ CPU, memory, database, network หรือ dependency ภายนอก

ข้อมูลเหล่านี้ใช้สำหรับ capacity planning, ตั้ง SLO/SLA และจับ regression ก่อน release

ประเภทหลักของการทดสอบประสิทธิภาพ

การทดสอบประสิทธิภาพไม่ใช่การทดสอบแบบเดียว แต่เป็นชุดของวิธีทดสอบที่ตอบคำถามต่างกัน

1. Baseline testing

Baseline testing คือการรันระบบภายใต้โหลดปกติที่คาดว่าจะเจอ แล้วบันทึกผลลัพธ์ไว้เป็นจุดอ้างอิง

ใช้ตอบคำถาม:

  • ภายใต้โหลดปกติ ระบบควรเร็วแค่ไหน?
  • release ใหม่ช้ากว่าเดิมหรือไม่?
  • ตัวเลขที่เห็น “ดี” หรือ “แย่” เมื่อเทียบกับอดีต?

ตัวอย่าง baseline ที่ควรเก็บ:

Endpoint: POST /login
Concurrency: 50 users
Duration: 10 minutes
p95 response time: 280 ms
p99 response time: 650 ms
Error rate: 0.02%
Throughput: 420 req/s
Enter fullscreen mode Exit fullscreen mode

ถ้าไม่มี baseline คุณจะไม่รู้ว่าตัวเลขใหม่คือปัญหาหรือเป็นพฤติกรรมปกติของระบบ

2. Load testing

Load testing คือการทดสอบด้วยปริมาณการใช้งานสูงสุดที่คาดว่าจะเกิดขึ้นจริง เช่น peak traffic ในวันทำงานหรือช่วง campaign

ใช้ตรวจสอบว่า:

  • response time ยังอยู่ใน budget หรือไม่
  • error rate ยังใกล้ศูนย์หรือไม่
  • throughput เพียงพอต่อ peak traffic หรือไม่

ตัวอย่างเป้าหมาย:

Expected peak: 1,000 concurrent users
Target p95 response time: < 500 ms
Target error rate: < 0.1%
Enter fullscreen mode Exit fullscreen mode

ถ้าระบบผ่าน load test แปลว่าระบบน่าจะรองรับวันทำงานที่ยุ่งที่สุดได้

3. Stress testing

Stress testing คือการเพิ่มโหลดเกินกว่าที่คาดไว้จนระบบเริ่มเสื่อมถอยหรือล้มเหลว

เป้าหมายไม่ใช่แค่ทำให้ระบบพัง แต่เพื่อดูว่า:

  • จุดแตกหักอยู่ที่โหลดระดับใด
  • ระบบ fail อย่างไร
  • มี graceful degradation หรือไม่
  • มี data loss หรือ cascading failure หรือไม่

พฤติกรรมที่ยอมรับได้:

โหลดสูงมาก → response time เพิ่มขึ้น → queue เต็ม → reject request บางส่วนด้วย 429
Enter fullscreen mode Exit fullscreen mode

พฤติกรรมที่ไม่ควรเกิด:

โหลดสูงมาก → database lock → service ทั้งหมด timeout → data corruption
Enter fullscreen mode Exit fullscreen mode

4. Spike testing

Spike testing คือการเพิ่มโหลดขึ้นอย่างรวดเร็ว แล้วลดลงอีกครั้ง เพื่อจำลองเหตุการณ์ที่ traffic พุ่งทันที เช่น flash sale, ข่าว viral หรือ webhook burst

ใช้ตอบคำถาม:

  • autoscaling ตอบสนองเร็วพอหรือไม่
  • connection pool รับ burst ได้หรือไม่
  • queue/backpressure ทำงานถูกต้องหรือไม่
  • cache warm-up ช้าเกินไปหรือไม่

ระบบที่รองรับโหลดคงที่ได้ดี อาจล้มเหลวเมื่อเจอ spike เพราะ scale ไม่ทัน

5. Capacity testing

Capacity testing คือการหาจำนวนโหลดสูงสุดที่ระบบรองรับได้โดยยังอยู่ใน performance budget

ผลลัพธ์ควรเป็นตัวเลขที่นำไปใช้ได้ เช่น:

ระบบรองรับได้สูงสุด 2,400 concurrent users
โดย p95 response time < 700 ms
และ error rate < 0.1%
Enter fullscreen mode Exit fullscreen mode

ตัวเลขนี้ใช้โดยตรงกับ:

  • capacity planning
  • autoscaling threshold
  • infrastructure sizing
  • release readiness decision

6. Soak testing

Soak testing หรือ stability/endurance testing คือการรันโหลดระดับปานกลางเป็นเวลานาน เช่น หลายชั่วโมงหรือหลายวัน

ใช้ตรวจหาปัญหาที่ไม่โผล่ในการทดสอบสั้น ๆ เช่น:

  • memory leak
  • connection leak
  • file descriptor หมด
  • queue ค่อย ๆ สะสม
  • response time ค่อย ๆ แย่ลง
  • cache หรือ session store โตไม่หยุด

ตัวอย่าง soak test:

Concurrency: 300 users
Duration: 12 hours
Target p95 response time: < 500 ms
Target error rate: < 0.1%
Monitor: memory, CPU, DB connections, GC, queue length
Enter fullscreen mode Exit fullscreen mode

โดยทั่วไป ทีมควรเริ่มจาก baseline, load และ soak testing แล้วเพิ่ม stress และ spike testing สำหรับระบบที่มี traffic สูงหรือคาดเดายาก

เมตริกที่ใช้นิยามผลลัพธ์

Performance test จะมีประโยชน์ก็ต่อเมื่อคุณวัดเมตริกที่ถูกต้อง

Response time

Response time คือเวลาตั้งแต่ส่ง request จนได้รับ response

อย่าดูแค่ค่าเฉลี่ย ให้ดู percentile เสมอ:

avg: 180 ms
p50: 120 ms
p95: 420 ms
p99: 2,800 ms
Enter fullscreen mode Exit fullscreen mode

ค่าเฉลี่ยอาจดูดี แต่ p99 อาจแย่มาก ผู้ใช้จริงมักรู้สึกถึง tail latency โดยเฉพาะในระบบที่มีหลาย request ต่อหนึ่งหน้า

Throughput

Throughput คือจำนวนงานที่ระบบทำเสร็จต่อหน่วยเวลา มักวัดเป็น requests per second

สูตรพื้นฐาน:

throughput = total completed requests / test duration
Enter fullscreen mode Exit fullscreen mode

ตัวอย่าง:

120,000 requests / 300 seconds = 400 req/s
Enter fullscreen mode Exit fullscreen mode

Throughput ช่วยบอกขีดความสามารถของระบบ แต่ต้องอ่านคู่กับ response time และ error rate เสมอ เพราะ throughput สูงแต่ error เยอะไม่ถือว่าดี

Concurrency

Concurrency คือจำนวนผู้ใช้หรือ connection ที่ทำงานพร้อมกัน

ตัวอย่างคำถามที่ควรตอบได้:

ระบบเริ่มเกิน p95 500 ms ที่ concurrency เท่าไร?
ระบบเริ่ม error rate > 1% ที่ concurrency เท่าไร?
Enter fullscreen mode Exit fullscreen mode

Concurrency ไม่เท่ากับ requests per second เสมอไป เพราะขึ้นกับพฤติกรรมผู้ใช้ ระยะเวลาคิดระหว่าง action และ latency ของแต่ละ request

Error rate

Error rate คือเปอร์เซ็นต์ของ request ที่ล้มเหลวภายใต้โหลด

ตัวอย่าง:

total requests: 100,000
failed requests: 75
error rate: 0.075%
Enter fullscreen mode Exit fullscreen mode

ระบบที่ยังตอบเร็วแต่เริ่มคืน 5xx จำนวนมากไม่ถือว่าผ่าน เพราะ performance ต้องรวม reliability ด้วย

CPU และ memory utilization

CPU และ memory ช่วยอธิบายว่าทำไมเมตริกอื่นเปลี่ยน

ตัวอย่างการอ่านผล:

p95 เพิ่มขึ้น + CPU 100%
→ อาจติด CPU-bound workload

p95 เพิ่มขึ้น + CPU ต่ำ
→ อาจติด database, lock, network หรือ external dependency

memory เพิ่มขึ้นเรื่อย ๆ ระหว่าง soak test
→ อาจมี memory leak หรือ cache eviction ไม่ทำงาน
Enter fullscreen mode Exit fullscreen mode

ผลลัพธ์ที่ดีควรเขียนได้เป็นประโยคเดียว เช่น:

ที่ 800 concurrent users ระบบทำ throughput ได้ 1,200 req/s, p95 อยู่ที่ 480 ms, error rate 0.05% และคอขวดหลักอยู่ที่ database connection pool

การทดสอบประสิทธิภาพเข้ากับกระบวนการอย่างไร

ในอดีต performance testing มักถูกทำช่วงท้ายโครงการก่อน release ครั้งเดียว วิธีนี้ไม่เหมาะกับระบบที่ deploy ต่อเนื่อง เพราะ performance regression เกิดได้จากการเปลี่ยนแปลงเล็ก ๆ เช่น:

  • query ใหม่ที่ไม่มี index
  • integration ใหม่ที่ latency สูง
  • payload ใหญ่ขึ้น
  • cache key เปลี่ยน
  • connection pool ไม่พอ
  • N+1 query

แนวทางที่ดีกว่าคือปฏิบัติกับ performance เหมือน correctness: ตรวจอย่างต่อเนื่องและมี budget ชัดเจน

ขั้นตอนที่แนะนำ

  1. เลือก critical path เช่น login, search, checkout, payment, create order
  2. กำหนด performance budget
  3. เขียน scenario test ที่จำลอง workflow จริง
  4. รัน lightweight load test ใน CI/CD
  5. ให้ build fail เมื่อ response time หรือ error rate เกิน budget
  6. รัน stress/soak test แบบ scheduled ก่อน release หรือเป็น nightly job

ตัวอย่าง budget:

performance_budget:
  login:
    p95_ms: 300
    p99_ms: 1000
    error_rate_percent: 0.1
  search:
    p95_ms: 500
    p99_ms: 1500
    error_rate_percent: 0.1
  checkout:
    p95_ms: 800
    p99_ms: 2000
    error_rate_percent: 0.05
Enter fullscreen mode Exit fullscreen mode

สำหรับระบบส่วนใหญ่ จุดที่คุ้มค่าที่สุดคือการทดสอบที่เลเยอร์ API เพราะ API มี business logic หลัก เรียกซ้ำได้ง่าย และไม่มี UI flakiness มารบกวน การทำ การทดสอบประสิทธิภาพ API ช่วยให้ได้ตัวเลขที่สม่ำเสมอและใช้ต้นทุนต่ำกว่า end-to-end UI test

การเก็บ performance test ไว้ใกล้กับ API functional test ยังช่วยให้ทุก change ถูกตรวจทั้งความถูกต้องและความเร็วพร้อมกัน

ข้อผิดพลาดทั่วไปในการทดสอบประสิทธิภาพ

Performance testing ทำผิดได้ง่าย และอาจให้ผลลัพธ์ที่ดูน่าเชื่อถือแต่ใช้ตัดสินใจไม่ได้ ข้อผิดพลาดที่พบบ่อยมีดังนี้

1. ทดสอบบน infrastructure ที่ไม่สมจริง

การรัน load test บน laptop หรือ staging environment ที่เล็กกว่า production มาก จะให้ตัวเลขที่ใช้ไม่ได้

ควรทำ:

  • ใช้ environment ที่ใกล้ production ที่สุด
  • ใช้ network path ที่ใกล้เคียงจริง
  • ใช้ database size ใกล้เคียงจริง
  • เปิด monitoring เหมือน production

ถ้าจำเป็นต้องใช้ staging ที่เล็กกว่า production ให้ระบุข้อจำกัดไว้ชัดเจน และใช้ผลลัพธ์เพื่อหา regression ไม่ใช่ capacity สุดท้าย

2. ไม่แยกช่วง warm-up

ระบบจำนวนมากช้าในช่วงแรก เพราะ cache ยังไม่เต็ม connection pool ยังไม่พร้อม หรือ JIT/initialization ยังทำงานอยู่

ควรแยกผลเป็น:

Warm-up: 2 minutes
Measurement: 10 minutes
Enter fullscreen mode Exit fullscreen mode

หรือรายงาน cold start และ steady state แยกกัน

3. อ่านค่าเฉลี่ยแทน percentile

ค่าเฉลี่ยซ่อน tail latency ได้ง่ายมาก เช่น:

avg: 200 ms
p99: 3,000 ms
Enter fullscreen mode Exit fullscreen mode

ผู้ใช้ที่เจอ p99 จะรู้สึกว่าระบบช้า แม้ค่าเฉลี่ยจะดูดี

ควรรายงานอย่างน้อย:

  • p50
  • p90
  • p95
  • p99
  • max
  • error rate

4. ใช้ข้อมูลทดสอบไม่สมจริง

ถ้าทุก request ใช้ user id เดียวหรือ product id เดียว database อาจตอบจาก cache เกือบทั้งหมด ทำให้ผลดูดีกว่าความจริง

ควรใช้ test data ที่กระจายเหมือน production เช่น:

{
  "userIds": ["u1001", "u1002", "u1003", "..."],
  "productIds": ["p2001", "p2002", "p2003", "..."],
  "searchTerms": ["phone", "laptop", "monitor", "..."]
}
Enter fullscreen mode Exit fullscreen mode

5. ทดสอบ endpoint เดียวแยกจาก workflow จริง

ผู้ใช้จริงไม่ได้เรียก endpoint เดียวซ้ำ ๆ แต่ทำ workflow เช่น:

login → browse → search → add to cart → checkout
Enter fullscreen mode Exit fullscreen mode

ถ้าทดสอบแค่ endpoint เดียว คุณอาจพลาด resource contention ระหว่างหลาย service, database table หรือ connection pool

ควรสร้าง scenario แบบ multi-step ที่ใกล้เคียง user journey จริง

6. ทำครั้งเดียวก่อน release

Performance test ที่รันครั้งเดียวก่อน release จะล้าสมัยทันทีเมื่อมี change ถัดไป

ควรทำให้เป็นกระบวนการต่อเนื่อง:

Pull request → lightweight load test
Nightly → broader load test
Pre-release → stress/spike/soak test
Production → monitoring + alerting
Enter fullscreen mode Exit fullscreen mode

การหลีกเลี่ยงข้อผิดพลาดเหล่านี้ช่วยให้ performance test กลายเป็นข้อมูลที่ใช้ตัดสินใจได้จริง ไม่ใช่แค่เครื่องหมายถูกสีเขียวที่ทำให้รู้สึกปลอดภัย

การรันการทดสอบประสิทธิภาพด้วย Apidog

Apidog รวมการออกแบบ API, functional testing และ load testing ไว้ใน workspace เดียวกัน จึงไม่ต้องดูแล API definition หลายชุดหรือย้าย scenario ไปมาระหว่างหลายเครื่องมือ

แนวทางใช้งานทั่วไปคือ:

  1. สร้าง endpoint หรือ สถานการณ์ทดสอบ แบบหลายขั้นตอน
  2. ตรวจให้ผ่านใน functional test ก่อน
  3. กำหนดจำนวน virtual users และระยะเวลาทดสอบ
  4. รัน load test
  5. ดู response time percentile, throughput และ error rate แบบ real time
  6. ระบุ concurrency level ที่ performance เริ่มเปลี่ยน
  7. ถ้าต้องการโหลดระดับใหญ่กว่าเครื่องเดียว สามารถส่งออก scenario ไปยัง JMeter โดยคง definition เดิมไว้

ตัวอย่าง workflow:

Create scenario: login → search → add to cart → checkout
Validate functional assertions
Run with 100 virtual users for 10 minutes
Check p95, p99, throughput, error rate
Compare with baseline
Fail the release if budget is exceeded
Enter fullscreen mode Exit fullscreen mode

ข้อดีคือ scenario เดียวกันใช้ได้ทั้ง functional run และ performance run ทำให้ดูแล artifact เดียว แทนที่จะต้องดูแล test script แยกหลายชุด

ดาวน์โหลด Apidog เพื่อเริ่ม profiling endpoint ที่คุณมีอยู่แล้ว

คำถามที่พบบ่อย

การทดสอบประสิทธิภาพกับการทดสอบฟังก์ชันแตกต่างกันอย่างไร?

Functional testing ตรวจว่าซอฟต์แวร์ให้ผลลัพธ์ถูกต้องหรือไม่ ส่วน performance testing ตรวจว่าซอฟต์แวร์ทำงานได้เร็วและเสถียรเพียงใดภายใต้โหลดจริง ทั้งสองอย่างจำเป็นและทดแทนกันไม่ได้

ควรเริ่มรันการทดสอบประสิทธิภาพประเภทใดก่อน?

เริ่มจาก baseline testing แล้วตามด้วย load testing

Baseline ให้ค่ามาตรฐานสำหรับเปรียบเทียบ ส่วน load testing ยืนยันว่าระบบรองรับ peak traffic ที่คาดไว้ได้ จากนั้นค่อยเพิ่ม stress, spike และ soak testing ตามความเสี่ยงของระบบ

ทำไมต้องใช้ percentile แทน response time เฉลี่ย?

ค่าเฉลี่ยซ่อนคำขอที่ช้าที่สุดได้ง่าย ในขณะที่ p95 และ p99 แสดงประสบการณ์ของผู้ใช้ที่เจอ latency แย่ที่สุด ซึ่งมักเป็นกลุ่มที่ร้องเรียนหรือออกจากระบบก่อน

การทดสอบประสิทธิภาพทำอัตโนมัติได้หรือไม่?

ได้ Lightweight load test สามารถรันใน CI ทุกครั้งที่มี pull request โดยกำหนด budget ให้ build fail เมื่อเกิด regression ส่วน stress และ soak test ที่ใช้เวลานานมักรันแบบ scheduled หรือก่อน release

ควรเริ่ม performance testing เมื่อใดในวงจรการพัฒนา?

ควรเริ่มเร็วที่สุดเท่าที่ทำได้ แม้ยังไม่มี infrastructure สุดท้าย คุณสามารถกำหนด performance budget และเขียน scenario ได้ตั้งแต่ช่วงออกแบบ เมื่อ endpoint ใช้งานได้แล้วจึงเริ่มรัน baseline/load test เพื่อจับปัญหาตั้งแต่ยังแก้ได้ง่าย

ใครควรรับผิดชอบ performance testing?

ในทีมสมัยใหม่ควรเป็นความรับผิดชอบร่วมกัน:

  • Developer รัน lightweight load test กับ change ของตัวเอง
  • QA ดูแล scenario และ performance budget
  • Ops/SRE ดูแล environment, monitoring และ server-side metrics

การมองว่า performance เป็นงานของผู้เชี่ยวชาญเพียงคนเดียวมักทำให้ปัญหาไปโผล่ใน production

Performance test ควรรันนานแค่ไหน?

ควรรันนานพอให้ผ่านช่วง warm-up และเข้าสู่ steady state

โดยทั่วไป:

Load test: หลายนาทีถึงหลักสิบ分钟
Stress test: จนกว่าจะเห็นจุดเสื่อมถอยหรือจุดแตกหัก
Spike test: สั้นแต่เพิ่มโหลดเร็ว
Soak test: หลายชั่วโมงหรือหลายวัน
Enter fullscreen mode Exit fullscreen mode

Soak test ต้องรันนานเป็นพิเศษ เพราะเป้าหมายคือหา degradation ที่เกิดช้า เช่น memory leak หรือ resource exhaustion ที่การรันสั้น ๆ มองไม่เห็น

Top comments (0)