📖 อ้างอิง 50+ คำศัพท์

Glossary — คำศัพท์ Performance Testing

คำศัพท์ที่ใช้บ่อยในงาน Performance Testing เรียงตามตัวอักษร พร้อมคำอธิบายที่เข้าใจง่ายและตัวอย่างการใช้งานจริง ใช้เป็น Reference ขณะอ่านบทความหรือเขียน Report

ALL A B C D E F G H L M P R S T V W

Acceptance Criteria KPI

เกณฑ์ที่กำหนดล่วงหน้าเพื่อตัดสินว่า Performance Test ผ่านหรือไม่ เช่น "p95 Response Time < 2s ที่ 1,000 Concurrent Users"

Apdex Score

Application Performance Index — คะแนน 0–1 ที่วัด User Satisfaction โดยอ้างอิงจาก Response Time ที่กำหนดเป็น T (Threshold)

APM (Application Performance Monitoring)

เครื่องมือ Monitor ประสิทธิภาพของ Application แบบ Real-time เช่น New Relic, Dynatrace, Datadog ช่วยหา Bottleneck ใน Code Level

API SLA Contract

ข้อตกลงระดับการให้บริการเฉพาะสำหรับ API แต่ละประเภท ตัวอย่าง: Read API p99 < 500ms, Write API p99 < 2s, Availability > 99.9% ควรกำหนดร่วมกับ Product Owner ก่อนเริ่ม Test และใช้เป็น Acceptance Criteria

Artillery

Modern Load Testing Tool ที่ใช้ YAML/JavaScript รองรับ HTTP, WebSocket และ Socket.io เหมาะกับ Node.js Teams

Baseline Test

การทดสอบเพื่อสร้างค่าอ้างอิง (Benchmark) ของ Performance ระบบในสภาวะปกติ ก่อน Load เพิ่มขึ้น ใช้เปรียบเทียบหลัง Code Change

Bottleneck

จุดที่ทำให้ระบบทำงานช้าหรือ Throughput ลดลง อาจเกิดจาก CPU, Memory, DB, Network หรือ Lock Contention

Breaking Point

ระดับ Load ที่ทำให้ระบบล้มเหลวหรือ Degrade อย่างรุนแรง ค้นหาด้วย Stress Test

Concurrency Metric

จำนวน User หรือ Process ที่ใช้งานระบบพร้อมกันในขณะใดขณะหนึ่ง แตกต่างจาก Simultaneous Users

Connection Pool

กลุ่ม Database Connection ที่สร้างไว้ล่วงหน้าและ Reuse ได้ ช่วยลด Overhead ของการสร้าง Connection ใหม่ทุกครั้ง ขนาด Pool ที่เหมาะสม ≈ Peak TPS × Avg Query Time

Connection Timeout

เวลาสูงสุดที่ Client รอก่อน Error เมื่อ Connection Pool เต็มหรือ Server ไม่ตอบ มักเป็น Root Cause ของ Error Rate พุ่งตอน Peak Load ต้องตั้งค่าให้เหมาะสมก่อนรัน Performance Test

CPU Utilization

เปอร์เซ็นต์การใช้งาน CPU — ควรอยู่ต่ำกว่า 70% ใน Sustained Load ถ้าสูงเกินไปอาจหมายถึง Algorithm ไม่มีประสิทธิภาพหรือ Thread Contention

Degradation

การเสื่อมประสิทธิภาพของระบบที่ค่อยๆ เกิดขึ้นตามเวลา มักพบใน Soak Test เช่น Response Time เพิ่มขึ้นเรื่อยๆ โดยไม่มี Load เพิ่ม

Distributed Testing

การรัน Load Test จาก Test Client หลายเครื่องพร้อมกัน เพื่อสร้าง Load ที่มากกว่าที่เครื่องเดียวจะทำได้ รองรับโดย JMeter, k6 Cloud, Locust

Endurance Test

ดู Soak Test — การทดสอบระยะยาวเพื่อหา Memory Leak และ Degradation

Error Rate Metric

เปอร์เซ็นต์ของ Request ที่ได้รับ Error Response (HTTP 4xx/5xx) หรือ Timeout ควรต่ำกว่า 1% สำหรับระบบทั่วไป

Flash Crowd

การที่ User จำนวนมากเข้าระบบพร้อมกันในทันทีทันใด เช่น ตอน Flash Sale หรือ Breaking News — จำลองด้วย Spike Test

Functional Testing vs Performance Testing

Functional Testing ตรวจสอบว่าระบบทำงาน "ถูกต้อง" ไหม ส่วน Performance Testing ตรวจสอบว่าระบบทำงาน "เร็วพอ" และ "เสถียรพอ" ไหม

Gatling

High-performance Load Testing Tool เขียนด้วย Scala สร้าง Interactive HTML Report ที่สวยงาม ใช้ Async I/O ทำให้รัน VU ได้มากด้วย Thread น้อย

Grafana

Platform สำหรับ Visualization Metrics ใช้ร่วมกับ Prometheus, InfluxDB เพื่อแสดง Real-time Dashboard ระหว่าง Performance Test

Horizontal Scaling (Scale Out)

การเพิ่มจำนวน Server Instance เพื่อรองรับ Load ที่เพิ่มขึ้น ตรงข้ามกับ Vertical Scaling (เพิ่ม CPU/RAM)

HTTP Status Code

รหัสตอบกลับ HTTP — 2xx = Success, 3xx = Redirect, 4xx = Client Error, 5xx = Server Error (ตัวชี้วัดหลักใน Error Rate)

Latency

ความล่าช้าในการส่งข้อมูลผ่านเครือข่าย วัดเป็น ms ส่งผลต่อ Response Time โดยตรง ต่างจาก Response Time ที่รวม Processing Time ด้วย

Little's Law

N = λ × W — สมการที่ใช้คำนวณ Concurrent Users (N) จาก Arrival Rate (λ) และ Response Time (W)

Load Test Test Type

การทดสอบระบบภายใต้ Workload ที่คาดหวัง (Expected Load) เพื่อยืนยัน Performance ตาม SLA

Locust

Open-source Load Testing Framework เขียนด้วย Python มี Web UI สำหรับ Monitor และรองรับ Distributed Testing

Mean Time to Recovery (MTTR)

เวลาเฉลี่ยที่ระบบใช้ในการกลับมาทำงานปกติหลังจากเกิด Failure ค่านี้วัดได้จาก Stress Test และ Spike Test

Memory Leak

ปัญหาที่ Application ใช้ Memory เพิ่มขึ้นเรื่อยๆ โดยไม่ Release ค้นพบได้จาก Soak Test ที่รัน Load นานๆ

Percentile (p50, p90, p95, p99)

การวัด Response Time ที่แม่นยำกว่า Average — p95 หมายถึง 95% ของ Request มี Response Time ต่ำกว่าค่านี้ ดีกว่าดู Average เพราะไม่ถูก Outlier บิดเบือน

Peak Factor

ตัวคูณที่ใช้แปลง Average TPS เป็น Peak TPS: Peak TPS = Average TPS × Peak Factor โดยทั่วไป Web Application ใช้ 2–5× ขึ้นอยู่กับ Business Pattern หาได้จาก Access Log ของ Production

Performance Testing

กระบวนการทดสอบที่ประเมิน Speed, Stability, Scalability และ Resource Usage ของระบบภายใต้ Workload ต่างๆ

Ramp-up Period

ช่วงเวลาที่ค่อยๆ เพิ่ม Virtual Users จาก 0 ไปถึงเป้าหมาย เพื่อไม่ให้ระบบรับ Load หนักทันทีตั้งแต่เริ่มต้น

Response Time Metric

เวลาที่ใช้ตั้งแต่ Client ส่ง Request จนได้รับ Response ครบถ้วน = Latency + Processing Time + Transfer Time

RPS / TPS

Requests Per Second / Transactions Per Second — Throughput ที่ระบบรองรับได้ต่อวินาที ยิ่งสูงยิ่งดี แต่ต้องดูควบคู่ Error Rate

Scalability Test Test Type

ทดสอบว่าระบบ Scale ได้ดีแค่ไหน เมื่อเพิ่ม Resource เช่น 2x Server ควรได้ ~2x Throughput

SLA (Service Level Agreement)

ข้อตกลงระหว่าง Provider และ Customer เกี่ยวกับระดับการให้บริการ เช่น Availability 99.9%, Response Time < 2s

Soak Test Test Type

รัน Load ต่อเนื่องนาน 8–72 ชั่วโมงเพื่อหา Memory Leak, Resource Exhaustion และ Performance Degradation

Spike Test Test Type

จำลอง Traffic ที่เพิ่มขึ้นอย่างรวดเร็วและฉับพลัน เพื่อทดสอบว่าระบบรับมือกับ Sudden Surge ได้หรือไม่

Stress Test Test Type

ทดสอบระบบเกิน Capacity ที่ออกแบบมาเพื่อหา Breaking Point และดูพฤติกรรมเมื่อล้มเหลว

TPH (Transactions Per Hour) Business Metric

จำนวน Business Transaction ที่เกิดขึ้นใน 1 ชั่วโมง ใช้แปลงเป็น TPS สำหรับ Performance Test ด้วยสูตร: TPS = TPH ÷ 3,600 ดีกว่าเริ่มจาก VU โดยตรงเพราะอิงจากข้อมูล Business จริง

Think Time

เวลาหยุดระหว่าง Request ใน Script เพื่อจำลองพฤติกรรมจริงของ User ที่ต้องอ่าน คิด หรือพิมพ์ข้อมูล โดยทั่วไป 1–5 วินาที

Threshold

ค่าสูงสุด/ต่ำสุดที่ยอมรับได้สำหรับแต่ละ Metric เช่น p95 < 2,000ms, Error Rate < 1% ใช้ Pass/Fail Test

Throughput Metric

จำนวน Transaction หรือ Request ที่ระบบประมวลผลได้ในหน่วยเวลา (TPS/RPS) วัดความสามารถในการรับ Load

Virtual User (VU)

User จำลองที่ Tool สร้างขึ้นเพื่อ Simulate พฤติกรรมของ User จริง แต่ละ VU จะรัน Script ซ้ำๆ ตลอด Duration

Volume Test Test Type

ทดสอบระบบด้วยปริมาณข้อมูลขนาดใหญ่ เพื่อดูว่า Performance ยังอยู่ในระดับที่ยอมรับได้เมื่อ Database โตขึ้นมาก

Working Hours / Business Hours

ช่วงเวลาที่ User ส่วนใหญ่ใช้งานระบบ ใช้คำนวณ Average TPS จาก Business Volume เช่น ระบบ B2B มักมี Working Hours 8–9 ชั่วโมง, E-commerce กระจาย 16–18 ชั่วโมง — สำคัญมากต่อการคำนวณ Peak Factor ที่แม่นยำ

Workload Model

แบบจำลองของ Traffic Pattern และพฤติกรรม User ที่ใช้ใน Performance Test รวมถึง Concurrent Users, Think Time, Transaction Mix

Warm-up Period

ช่วงเวลาเริ่มต้นที่ให้ระบบ "อุ่นเครื่อง" ก่อนวัดผลจริง เช่น JVM JIT Compilation, Cache Warming ข้อมูลในช่วงนี้มักไม่นับใน Result