#การทำ Load Test ด้วย Apache JMeter

การทำ Load Testing เป็นกระบวนการทดสอบประสิทธิภาพของระบบภายใต้ภาระงานที่ใกล้เคียงกับการใช้งานจริง เช่น การจำลองผู้ใช้งานหลายร้อยหรือหลายพันคนที่เข้าถึง Web Application หรือ REST API พร้อมกัน

เครื่องมือที่นิยมใช้สำหรับงานประเภทนี้คือ Apache JMeter ซึ่งสามารถจำลอง Virtual Users, ส่ง HTTP Requests, ตรวจสอบ Response, อ่านข้อมูลจาก CSV, ดึงค่าจาก JSON และสร้างรายงานผลในรูปแบบ HTML ได้

บทความนี้อธิบายแนวทางสร้าง Load Test ด้วย JMeter ตั้งแต่พื้นฐานจนถึงการรันแบบ CLI สำหรับใช้งานจริง

#Load Testing คืออะไร

Load Testing คือการตรวจสอบว่าระบบสามารถรองรับภาระงานตามที่คาดไว้ได้หรือไม่ เช่น

  • ผู้ใช้งานพร้อมกัน 100 คน
  • ผู้ใช้งานพร้อมกัน 500 คน
  • 300 Requests ต่อวินาที
  • การ Login พร้อมกันจำนวนมาก
  • การเรียก API ต่อเนื่องเป็นเวลาหลายนาทีหรือหลายชั่วโมง

ตัวอย่าง Scenario:

ผู้ใช้ 100 คน
   │
   ├── Login
   │
   ├── ดูรายการสินค้า
   │
   └── สร้างคำสั่งซื้อ

เป้าหมายหลักของ Load Test คือวัดค่าต่าง ๆ เช่น

  • Response Time
  • Throughput
  • Error Rate
  • Latency
  • Percentile เช่น P90, P95 และ P99
  • จำนวน Concurrent Users ที่ระบบรองรับได้

#Apache JMeter คืออะไร

Apache JMeter เป็นเครื่องมือ Open Source สำหรับ Performance Testing และ Load Testing

JMeter รองรับการทดสอบหลายรูปแบบ เช่น

  • HTTP / HTTPS
  • REST API
  • SOAP
  • JDBC
  • FTP
  • TCP
  • JMS

สำหรับ Web Application และ API งานส่วนใหญ่จะใช้ HTTP Request Sampler

#ตัวอย่างระบบที่ต้องการทดสอบ

สมมติว่ามี REST API ดังนี้

POST /api/login
GET /api/products
POST /api/orders

เราต้องการจำลองพฤติกรรมผู้ใช้ตามลำดับ

Login
  ↓
ดูรายการสินค้า
  ↓
สร้าง Order

โครงสร้าง Test Plan ใน JMeter อาจเป็นดังนี้

Test Plan
└── Thread Group
    ├── HTTP Request Defaults
    ├── HTTP Header Manager
    ├── CSV Data Set Config
    ├── Login
    │   ├── JSON Extractor
    │   └── Response Assertion
    ├── Get Products
    ├── Create Order
    ├── Timer
    └── Summary Report

#1. ติดตั้ง Java

JMeter ทำงานบน Java ดังนั้นควรตรวจสอบ Java ก่อน

java -version

หาก Java ติดตั้งเรียบร้อย ระบบจะแสดงเวอร์ชันของ Java

#2. เปิดใช้งาน JMeter

หลังจากดาวน์โหลด Apache JMeter และแตกไฟล์แล้ว

บน macOS หรือ Linux:

cd apache-jmeter/bin
./jmeter

บน Windows:

jmeter.bat

GUI เหมาะสำหรับสร้างและ Debug Test Plan แต่ไม่ควรใช้ GUI สำหรับ Load Test ขนาดใหญ่

#3. สร้าง Test Plan

ใน JMeter เลือก

Test Plan
→ Add
→ Threads (Users)
→ Thread Group

ตัวอย่างค่าที่กำหนด

Number of Threads (Users): 100
Ramp-up Period:             60
Loop Count:                 5

ความหมายคือ

  • จำลองผู้ใช้ 100 คน
  • ใช้เวลา 60 วินาทีในการเพิ่มผู้ใช้ครบ 100 คน
  • ผู้ใช้แต่ละคนทำ Scenario ซ้ำ 5 รอบ

จำนวนผู้ใช้ที่ถูกเพิ่มโดยเฉลี่ยคือ

100 / 60
≈ 1.67 users/sec

การใช้ Ramp-up ช่วยลดปัญหาการส่ง Request จำนวนมากเข้าสู่ระบบพร้อมกันในวินาทีแรก

#4. กำหนด HTTP Request Defaults

เพิ่ม

Thread Group
→ Add
→ Config Element
→ HTTP Request Defaults

ตัวอย่าง

Protocol: https
Server Name: api.example.com

หลังจากนั้น HTTP Request แต่ละรายการสามารถกำหนดเพียง Path เช่น

/api/login
/api/products
/api/orders

ข้อดีคือไม่ต้องกำหนด Domain ซ้ำทุก Request

#5. เพิ่ม HTTP Header Manager

เพิ่ม

Thread Group
→ Add
→ Config Element
→ HTTP Header Manager

ตัวอย่าง Header

Content-Type: application/json
Accept: application/json

ถ้าระบบใช้ JWT Token สามารถเพิ่มภายหลังได้ เช่น

Authorization: Bearer ${token}

#6. สร้าง Login Request

เพิ่ม HTTP Request

Thread Group
→ Add
→ Sampler
→ HTTP Request

กำหนด

Name: Login
Method: POST
Path: /api/login

ตัวอย่าง Request Body

{
  "email": "test@example.com",
  "password": "password"
}

สมมติ API ส่ง Response

{
  "token": "eyJhbGciOi..."
}

เราสามารถดึง Token ไปใช้กับ Request อื่นได้

#7. ดึง JWT Token ด้วย JSON Extractor

คลิกขวาที่ Login Request แล้วเพิ่ม

Login
→ Add
→ Post Processors
→ JSON Extractor

กำหนด

Names of created variables:
token

JSON Path Expressions:
$.token

หลังจากนั้นสามารถเรียกใช้ตัวแปรได้ด้วย

${token}

นำไปใช้กับ HTTP Header Manager

Authorization: Bearer ${token}

#8. เรียก Products API

สร้าง HTTP Request ใหม่

Name: Get Products
Method: GET
Path: /api/products

ถ้า API ต้องใช้ JWT Token JMeter จะส่ง Header ที่กำหนดไว้ให้

โครงสร้างจะเป็น

Thread Group
├── Login
├── Get Products
└── Create Order

#9. สร้าง Order Request

เพิ่ม Request

Method: POST
Path: /api/orders

ตัวอย่าง Body

{
  "product_id": 10,
  "quantity": 2
}

ถ้าต้องการใช้ข้อมูล Dynamic สามารถใช้ตัวแปรของ JMeter

{
  "product_id": "${productId}",
  "quantity": "${quantity}"
}

#10. ใช้ CSV Data Set Config

ในการ Load Test ไม่ควรให้ Virtual Users ทุกคน Login ด้วย Account เดียว เพราะอาจไม่สะท้อนการใช้งานจริง

สร้างไฟล์

users.csv

ตัวอย่าง

email,password
user001@example.com,password123
user002@example.com,password123
user003@example.com,password123
user004@example.com,password123

เพิ่ม

Thread Group
→ Add
→ Config Element
→ CSV Data Set Config

กำหนด

Filename:
users.csv

Variable Names:
email,password

จากนั้นเปลี่ยน Login Request Body เป็น

{
  "email": "${email}",
  "password": "${password}"
}

Virtual User แต่ละคนจะสามารถใช้ข้อมูลจาก CSV ได้

#11. เพิ่ม Think Time

ผู้ใช้จริงไม่ได้ส่ง Request ต่อเนื่องโดยไม่มีช่วงเวลาเว้น

ตัวอย่างพฤติกรรมจริง

เปิดหน้า Product
      ↓
อ่านข้อความ 2 วินาที
      ↓
เลือกสินค้า
      ↓
รอ 3 วินาที
      ↓
สร้าง Order

ใน JMeter สามารถใช้ Timer เช่น

Add
→ Timer
→ Uniform Random Timer

ตัวอย่าง

Random Delay Maximum:
2000 ms

Constant Delay Offset:
1000 ms

ทำให้ Request มี Delay ประมาณ

1–3 วินาที

ซึ่งช่วยให้ Workload ใกล้เคียงพฤติกรรมผู้ใช้จริงมากขึ้น

#12. ตรวจสอบผลด้วย Response Assertion

การที่ API ตอบ HTTP 200 ไม่ได้หมายความว่า Business Logic ถูกต้องเสมอไป

สามารถเพิ่ม Assertion

HTTP Request
→ Add
→ Assertions
→ Response Assertion

ตัวอย่างตรวจ Status Code

200

หรือตรวจ Response Body ว่ามีข้อความ

success

แนวทางที่ดีคือควรตรวจสอบอย่างน้อย

  • HTTP Status
  • Response Body
  • Business Result

#13. Listener สำหรับดูผล

ระหว่างพัฒนา Test Plan สามารถใช้ Listener เช่น

View Results Tree
Summary Report
Aggregate Report
Response Time Graph

แต่ควรระวังว่า

View Results Tree ใช้หน่วยความจำสูงและไม่เหมาะกับ Load Test ขนาดใหญ่

แนวทางที่เหมาะสมคือ

Debug
→ ใช้ GUI
→ 1–20 Users
→ View Results Tree

ส่วนการ Load Test จริง

Production-like Test
→ ใช้ CLI
→ หลายร้อย/หลายพัน Users
→ สร้าง HTML Report

#Metrics สำคัญที่ควรวิเคราะห์

#Response Time

ตัวอย่าง

Average  = 420 ms
Median   = 350 ms
P90      = 700 ms
P95      = 920 ms
P99      = 1,500 ms

ค่า P95 หมายถึง

95% ของ Requests
มี Response Time ไม่เกิน 920 ms

ในการวิเคราะห์ประสิทธิภาพ ควรดู Percentile ควบคู่กับ Average

#Throughput

สมมติรายงานแสดง

Throughput = 250 requests/sec

หมายความว่าระบบสามารถประมวลผลได้ประมาณ 250 Requests ต่อวินาทีภายใต้ Workload ที่กำลังทดสอบ

#Error Rate

สมมติ

Requests = 100,000
Errors   = 500

คำนวณ Error Rate ได้ประมาณ

500 / 100000 × 100
= 0.5%

ควรกำหนดเกณฑ์ก่อนทดสอบ เช่น

Error Rate < 1%

#ตัวอย่าง Acceptance Criteria

ก่อนเริ่ม Load Test ควรกำหนดเกณฑ์ให้ชัดเจน เช่น

Metric Target
Concurrent Users 500
Average Response Time < 500 ms
P95 < 1,000 ms
P99 < 2,000 ms
Error Rate < 1%
Throughput ≥ 300 req/s

ทำให้สามารถสรุปผลหลังการทดสอบได้อย่างชัดเจนว่า

PASS
หรือ
FAIL

#การรัน JMeter แบบ CLI

สมมติ Test Plan ชื่อ

load-test.jmx

รันด้วย

jmeter -n \
  -t load-test.jmx \
  -l results.jtl

ความหมาย

-n  = Non-GUI Mode
-t  = Test Plan
-l  = Result File

#สร้าง HTML Report

สามารถสั่งให้ JMeter สร้าง HTML Dashboard ได้ด้วย

jmeter -n \
  -t load-test.jmx \
  -l results.jtl \
  -e \
  -o report

จากนั้นเปิด

report/index.html

Dashboard จะมีข้อมูลสำคัญ เช่น

  • APDEX
  • Response Time
  • Throughput
  • Errors
  • Latency
  • Percentiles
  • Active Threads
  • Transactions per Second

#กำหนด Users ผ่าน Command Line

ไม่ควร Fix จำนวน Users ไว้ในไฟล์ .jmx เสมอไป

สามารถกำหนด Thread Group เป็น

Threads:
${__P(users,10)}

Ramp-up:
${__P(rampup,30)}

Duration:
${__P(duration,300)}

จากนั้นรัน

jmeter -n \
  -t load-test.jmx \
  -Jusers=500 \
  -Jrampup=120 \
  -Jduration=600 \
  -l results.jtl \
  -e \
  -o report

ทำให้ Test Plan เดียวสามารถใช้ทดสอบหลายระดับ Load

เช่น

-Jusers=100

หรือ

-Jusers=500

หรือ

-Jusers=1000

#ออกแบบ Load Test เป็น Stage

ไม่ควรเริ่มทดสอบด้วย Load สูงมากทันที

ตัวอย่าง

Stage 1
100 Users
5 Minutes

     ↓

Stage 2
250 Users
10 Minutes

     ↓

Stage 3
500 Users
15 Minutes

     ↓

Stage 4
1000 Users
15 Minutes

เป้าหมายคือสังเกตว่าเมื่อ Load เพิ่มขึ้น

Response Time ↑
Throughput     ↑
Error Rate     →

หรือเมื่อระบบเริ่มอิ่มตัว

Response Time ↑↑
Throughput     ─────
Error Rate     ↑↑

เมื่อจำนวน User เพิ่มขึ้นแต่ Throughput ไม่เพิ่ม และ Response Time สูงขึ้นอย่างรวดเร็ว ระบบอาจเข้าสู่ Saturation Point

#Load Test กับ Stress Test ต่างกันอย่างไร

#Load Test

ทดสอบภายใต้ระดับ Load ที่คาดว่าจะเกิดขึ้นจริง

Expected Workload
       ↓
ตรวจสอบว่าระบบผ่าน SLA/SLO หรือไม่

ตัวอย่าง

ระบบต้องรองรับ 500 Concurrent Users

#Stress Test

เพิ่ม Load ต่อเนื่องจนระบบเริ่มผิดพลาด

100 Users
   ↓
500 Users
   ↓
1000 Users
   ↓
2000 Users
   ↓
5000 Users
   ↓
System Failure

เป้าหมายคือหา

Breaking Point

ของระบบ

#ตัวอย่าง Architecture สำหรับ Load Test

                 JMeter
                   │
            Virtual Users
                   │
                   ▼
             Load Balancer
                   │
          ┌────────┴────────┐
          ▼                 ▼
       App #1            App #2
          │                 │
          └────────┬────────┘
                   ▼
                 Redis
                   │
                   ▼
                 MySQL

การวิเคราะห์ Load Test ไม่ควรดูเฉพาะข้อมูลจาก JMeter

ควรตรวจสอบ Infrastructure Metrics ด้วย เช่น

  • CPU
  • Memory
  • Disk I/O
  • Network
  • Database Connections
  • Slow Queries
  • Redis
  • Application Errors
  • JVM Heap
  • Garbage Collection

เครื่องมือที่สามารถใช้ร่วมกันได้ เช่น

JMeter
   +
Prometheus
   +
Grafana

#ตัวอย่างการวิเคราะห์ Bottleneck

สมมติเมื่อเพิ่ม Load เป็น 500 Users พบว่า

DB Connections = 100%

P95
400 ms
   ↓
4500 ms

Error Rate
0.2%
   ↓
8%

จากข้อมูลนี้อาจสันนิษฐานได้ว่า Bottleneck อยู่ที่

Database Connection Pool

ไม่ใช่ Web Server

จากนั้นสามารถปรับ Connection Pool แล้ว Load Test ใหม่เพื่อเปรียบเทียบผล

#Workflow ที่แนะนำ

กระบวนการ Performance Testing ที่เหมาะสมสามารถจัดเป็น

1. Define Workload
        ↓
2. Define SLA / SLO
        ↓
3. Create JMeter Test Plan
        ↓
4. Validate ด้วย 1–10 Users
        ↓
5. ตรวจสอบ Script และ Assertions
        ↓
6. Run Load Test แบบ CLI
        ↓
7. Collect JMeter Metrics
        ↓
8. Collect Server Metrics
        ↓
9. Identify Bottleneck
        ↓
10. Optimize System
        ↓
11. Re-test

#แนวทางสำหรับการเรียนการสอน

สำหรับ Workshop หรือห้องปฏิบัติการ สามารถออกแบบ Lab ให้ผู้เรียนทำตามลำดับ

REST API
   ↓
JMeter Thread Group
   ↓
HTTP Request
   ↓
CSV Data Set
   ↓
JSON Extractor
   ↓
Assertions
   ↓
Load Test
   ↓
CLI
   ↓
HTML Dashboard

หัวข้อดังกล่าวครอบคลุมองค์ประกอบสำคัญของ Performance Testing และสามารถต่อยอดไปสู่ CI/CD ได้

#การนำ JMeter ไปใช้ใน CI/CD

เมื่อมีไฟล์ .jmx แล้ว สามารถนำไปใช้กับ Pipeline เช่น

  • GitHub Actions
  • Jenkins
  • GitLab CI/CD
  • Azure DevOps

แนวคิดคือให้ Pipeline ทำงานตามลำดับ

Build
  ↓
Deploy Test Environment
  ↓
Run Functional Tests
  ↓
Run JMeter
  ↓
Generate Report
  ↓
ตรวจ SLA / SLO
  ↓
PASS / FAIL

สามารถพัฒนาไปสู่ Performance Regression Testing ได้ เช่น ตรวจสอบว่าเวอร์ชันใหม่ของระบบทำให้ P95 ช้าลงหรือ Error Rate สูงขึ้นหรือไม่

#สรุป

Apache JMeter เป็นเครื่องมือที่เหมาะสำหรับการทำ Load Testing ของ Web Application และ REST API เพราะสามารถจำลองผู้ใช้จำนวนมากและรองรับองค์ประกอบสำคัญ เช่น

  • Thread Group
  • HTTP Request
  • CSV Data Set
  • JSON Extractor
  • Assertions
  • Timers
  • CLI
  • HTML Dashboard

แนวทางที่แนะนำคือใช้ GUI สำหรับสร้างและ Debug Test Plan แล้วรัน Load Test จริงด้วย CLI

สิ่งสำคัญที่สุดคือไม่ควรวัดเพียงจำนวน Users แต่ควรพิจารณาร่วมกันทั้ง

Concurrent Users
+
Response Time
+
Percentile
+
Throughput
+
Error Rate
+
Infrastructure Metrics

เมื่อเก็บข้อมูลเหล่านี้ร่วมกัน จะช่วยให้ค้นหา Bottleneck และประเมินความสามารถของระบบได้แม่นยำขึ้น

#ตัวอย่างคำสั่งสรุป

รัน Test Plan:

jmeter -n -t load-test.jmx -l results.jtl

สร้าง HTML Report:

jmeter -n \
  -t load-test.jmx \
  -l results.jtl \
  -e \
  -o report

รันพร้อมกำหนดจำนวน Users:

jmeter -n \
  -t load-test.jmx \
  -Jusers=500 \
  -Jrampup=120 \
  -Jduration=600 \
  -l results.jtl \
  -e \
  -o report

แนวทางนี้เหมาะสำหรับทั้งการเรียนการสอน การทดสอบระบบจริง และการนำ Performance Testing เข้าไปเป็นส่วนหนึ่งของ DevOps และ CI/CD Pipeline