Khi hệ thống xử lý theo mô hình bất đồng bộ (asynchronous) — trong đó API nhận dữ liệu, đẩy vào hàng đợi (queue), và worker chạy nền (trên EC2) xử lý dần — việc đánh giá khả năng chịu tải không chỉ là đo tốc độ phản hồi API mà là đánh giá toàn bộ chuỗi xử lý message.

Stress test giúp xác định hệ thống có thể hấp thụ và xử lý bao nhiêu message mỗi giây, khi worker EC2 thực thi song song trên nhiều thread. Đây là bài test quan trọng để tối ưu số lượng instance, cấu hình thread pool và giới hạn throughput của hàng đợi SQS.

• Đo thời gian trung bình để xử lý một lượng lớn message.
• Xác định giới hạn throughput trước khi queue backlog.
• Phát hiện điểm nghẽn (bottleneck) ở tầng API, SQS hoặc Worker.
• Đánh giá mức ổn định và khả năng phục hồi khi tải giảm.

2. Kiến trúc hạ tầng dùng để stress test

Dưới đây là kiến trúc tham chiếu của hệ thống AWS EC2 Worker & SQS trong bài test:

3. Chuẩn bị dữ liệu test

Dữ liệu test cần mô phỏng hành vi thật của hệ thống, bao gồm payload gửi vào API và cấu hình tốc độ bắn tải. Thông thường, các test case được lưu trong file Excel — mỗi sheet là một loại test (load, spike, stability…).

Ví dụ: Kết quả thực tế Case 1 (500 threads / 60 giây)

Dưới đây là kết quả kiểm thử được ghi nhận (theo file Excel và log giám sát thực tế):

Trong bài test này (Case 1), hệ thống được giả lập với 500 người dùng đồng thời trong vòng 60 giây.

Kết quả cho thấy throughput trung bình đạt khoảng 8.3 requests/giây với 100% thành công, thời gian phản hồi trung bình là 227ms và cực đại là 307ms.

Điều này cho thấy hệ thống có khả năng xử lý ổn định ở mức tải trung bình.

Jmeter

EC2

Worker

RDS

SQS

Mẫu Jmeter setting

CSV Data Set Config: Filename: data_test.csv 
Variable Names: message_id,payload 
Recycle on EOF: True 
HTTP Body: { 
  "messageId": "${message_id}",
  "payload": "${payload}",
  "timestamp": "${__time(yyyy-MM-dd'T'HH:mm:ss)}"
 }

4. Cấu hình JMeter để gửi dữ liệu lên AWS

Công cụ được sử dụng là Apache JMeter — chuyên dùng để tạo tải HTTP và kiểm tra hiệu năng API. Mỗi request được gửi tới API Gateway, sau đó dữ liệu được đẩy vào hàng đợi SQS để worker EC2 xử lý.

Thread Group:
  Number of Threads (users): 500
  Ramp-up Period: 60
  Loop Count: 1

HTTP Request Sampler:
  Method: POST
  URL: https://{api-id}.execute-api.{region}.amazonaws.com/prod/push
  Body Data:
  {
    "messageId": "${__UUID()}",
    "payload": "${__RandomString(32,ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890)}",
    "timestamp": "${__time(yyyy-MM-dd'T'HH:mm:ss)}"
  }

HTTP Header Manager:
  Content-Type: application/json
  x-api-key: ${API_KEY}

Chạy test bằng chế độ non-GUI để tiết kiệm tài nguyên:

jmeter -n -t HTTPRequest_500_60_001.jmx -l results.csv -JAPI_KEY=xxxx

Nếu cần mô phỏng tăng tải dần, bạn có thể dùng plugin Stepping Thread Group để tăng số luồng từng giai đoạn, giúp kết quả thực tế hơn.

5. Giám sát EC2 Worker và hàng đợi SQS

Trong quá trình test, CloudWatch là công cụ chính để giám sát hệ thống. Các metric cần chú ý:

6. Phân tích kết quả và đánh giá hệ thống

Sau khi test, cần đối chiếu kết quả từ JMeter (thời gian phản hồi, throughput) với metric từ CloudWatch (queue depth, CPU, backlog). Một hệ thống tốt là khi:

• Queue depth không tăng mãi, mà dao động quanh ngưỡng ổn định.
• CPU trên EC2 được sử dụng hiệu quả (~60–80%), không nghẽn 100% liên tục.
• Throughput duy trì ổn định trong suốt thời gian test.
• Số message trong DLQ = 0 hoặc rất thấp.

7. Kết luận

Stress test trên AWS EC2 Worker và SQS giúp bạn hiểu được giới hạn chịu tải của hệ thống cũng như khả năng tự phục hồi sau khi backlog. Khi theo dõi đúng metric và xác định rõ “ngưỡng nghẽn” (bottleneck), bạn có thể điều chỉnh thread pool, số lượng EC2 instance hoặc kích thước hàng đợi để đạt hiệu suất tối ưu.

Tài liệu tham khảo

• Amazon SQS Monitoring Guide
• Amazon EC2 Monitoring
• Apache JMeter User Manual
• AWS Compute Blog

The post Stress Test with AWS Worker appeared first on Tomoshare.