DEV Community

Cover image for ApacheBench (ab): Cách kiểm tra tải API bằng dòng lệnh
Sebastian Petrus
Sebastian Petrus

Posted on • Originally published at apidog.com

ApacheBench (ab): Cách kiểm tra tải API bằng dòng lệnh

Bạn đã triển khai một endpoint. Nó trả về JSON đúng trong Postman. Nhưng khi 200 client gọi cùng lúc thì sao? Endpoint có chịu được 500 request/giây không, hay latency bắt đầu tăng mạnh ở mức concurrency 50? ApacheBench giúp bạn trả lời nhanh bằng một lệnh.

Dùng thử Apidog hôm nay

ApacheBench, thường gọi là ab, là công cụ dòng lệnh gửi một số lượng HTTP request cố định đến một URL và trả về các chỉ số như throughput, latency, request lỗi và percentile. Nó đi kèm Apache HTTP Server, nhỏ gọn, chạy nhanh, phù hợp để benchmark nhanh một endpoint đơn lẻ.

Bài viết này hướng dẫn cách cài ab, chạy test GET/POST, đọc kết quả, thêm header, xuất dữ liệu và xác định khi nào nên chuyển sang công cụ khác. Các lệnh đều dựa trên flag trong tài liệu Apache ab chính thức.

ApacheBench là gì?

ab là một HTTP benchmark client. Nó mở kết nối đến một URL, gửi request theo mức concurrency bạn đặt, đo thời gian phản hồi và in báo cáo tổng hợp.

ApacheBench

ab hữu ích nhất khi bạn cần trả lời nhanh các câu hỏi:

  • Endpoint xử lý được bao nhiêu request/giây?
  • Latency trung bình là bao nhiêu?
  • P95/P99 latency có tăng mạnh khi concurrency tăng không?
  • Khi nào server bắt đầu trả lỗi?

Phạm vi của ab khá hẹp:

  • Không validate nội dung JSON.
  • Không kiểm tra schema.
  • Không assert field trong response.
  • Không chạy flow nhiều bước như login → lấy token → tạo tài nguyên → đọc lại.
  • Chỉ benchmark một URL trong mỗi lần chạy.

Vì vậy, hãy dùng ab để đo tải nhanh cho một endpoint. Nếu cần kiểm thử chức năng hoặc flow API nhiều bước, hãy dùng công cụ khác bên cạnh nó.

Nếu bạn muốn hiểu rộng hơn về bối cảnh kiểm thử tải, xem thêm kiểm thử tải API là gì và tại sao thời gian phản hồi API lại quan trọng.

Cài đặt ab

ab nằm trong bộ tiện ích của Apache. Tên package khác nhau theo hệ điều hành.

Debian / Ubuntu 

sudo apt-get update
sudo apt-get install -y apache2-utils
Enter fullscreen mode Exit fullscreen mode

Kiểm tra:

ab -V
Enter fullscreen mode Exit fullscreen mode

CentOS / RHEL / Fedora 

# CentOS 7
sudo yum install -y httpd-tools

# Fedora và CentOS 8+
sudo dnf install -y httpd-tools
Enter fullscreen mode Exit fullscreen mode

Kiểm tra:

ab -V
Enter fullscreen mode Exit fullscreen mode

macOS

Trên macOS, ab thường đã có sẵn vì hệ thống đi kèm Apache:

ab -V
Enter fullscreen mode Exit fullscreen mode

Nếu không có, bạn có thể cài Apache qua Homebrew. Khi ab -V trả về version như Version 2.3, bạn đã sẵn sàng.

Chạy kiểm thử tải GET cơ bản

Hai flag quan trọng nhất là:

  • -n requests: tổng số request sẽ gửi.
  • -c concurrency: số request chạy đồng thời.

Ví dụ: gửi 1000 request, concurrency 50:

ab -n 1000 -c 50 https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Lưu ý: ab cần URL đầy đủ có path. Nếu benchmark root, thêm dấu /:

ab -n 1000 -c 50 https://api.example.com/
Enter fullscreen mode Exit fullscreen mode

Bật KeepAlive với -k

Client thực tế thường tái sử dụng TCP connection thay vì mở connection mới cho từng request. Thêm -k để bật HTTP KeepAlive:

ab -n 1000 -c 50 -k https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Nên chạy cả hai phiên bản:

ab -n 1000 -c 50 https://api.example.com/v1/users
ab -n 1000 -c 50 -k https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

So sánh kết quả để biết latency của bạn bị ảnh hưởng bao nhiêu bởi chi phí tạo connection.

Chạy theo thời gian với -t

Nếu muốn chạy trong một khoảng thời gian cố định, dùng -t:

ab -t 30 -c 50 -k https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Lệnh này chạy tối đa 30 giây với concurrency 50. -t ngầm đặt -n 50000, nên test dừng khi đạt giới hạn thời gian hoặc số request.

Kiểm thử endpoint POST

Với POST, bạn cần:

  1. Tạo file payload.
  2. Truyền payload bằng -p.
  3. Set Content-Type bằng -T.

Tạo file JSON:

cat > payload.json <<'EOF'
{"name": "Ada Lovelace", "email": "ada@example.com"}
EOF
Enter fullscreen mode Exit fullscreen mode

Gửi POST request:

ab -n 500 -c 25 -k \
  -p payload.json \
  -T application/json \
  https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Ý nghĩa các flag:

  • -p payload.json: file chứa body POST.
  • -T application/json: header Content-Type.
  • -n 500: tổng số request.
  • -c 25: 25 request đồng thời.
  • -k: dùng KeepAlive.

Nếu không set -T application/json, ab mặc định dùng text/plain, điều này thường không đúng với JSON API.

Thêm header và token xác thực

Dùng -H để thêm HTTP header. Có thể lặp lại nhiều lần.

Ví dụ với Bearer token:

ab -n 500 -c 25 -k \
  -p payload.json \
  -T application/json \
  -H "Authorization: Bearer YOUR_TOKEN" \
  https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Ví dụ thêm nhiều header:

ab -n 500 -c 25 -k \
  -p payload.json \
  -T application/json \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "X-Request-Source: load-test" \
  https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Nếu cần ôn lại cách tạo JSON request thủ công, xem cách POST dữ liệu JSON bằng curl. Payload dùng cho curl cũng có thể dùng làm file -p cho ab.

Đọc kết quả ApacheBench

Một lần chạy ab sẽ in ra báo cáo dạng sau:

Concurrency Level:      50
Time taken for tests:   4.212 seconds
Complete requests:      1000
Failed requests:        0
Non-2xx responses:      0
Requests per second:    237.42 [#/sec] (mean)
Time per request:       210.598 [ms] (mean)
Time per request:       4.212 [ms] (mean, across all concurrent requests)
Transfer rate:          142.31 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        5   18   9.4     16      64
Processing:    22  189  41.2    182     310
Waiting:       21  177  39.8    171     295
Total:         31  207  42.7    201     338

Percentage of the requests served within a certain time (ms)
  50%    201
  66%    221
  75%    236
  90%    268
  95%    291
  99%    324
 100%    338 (longest request)
Enter fullscreen mode Exit fullscreen mode

Tập trung vào các chỉ số sau.

1. Failed requests 

Failed requests:        0
Enter fullscreen mode Exit fullscreen mode

Nếu số này lớn hơn 0, đừng vội tin vào throughput. Cần kiểm tra nguyên nhân lỗi trước.

Lưu ý: ab có thể đánh dấu request là failed nếu response length thay đổi giữa các request. Điều này thường gặp với JSON động. Khi đó, thêm -l:

ab -n 1000 -c 50 -k -l https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

-l yêu cầu ab không xem khác biệt độ dài response là lỗi.

2. Non-2xx responses 

Non-2xx responses:      0
Enter fullscreen mode Exit fullscreen mode

Chỉ số này cho biết server có trả mã ngoài nhóm 2xx không. Nếu có nhiều 500, 429, 503, endpoint có thể đang bị quá tải hoặc bị rate limit.

3. Requests per second 

Requests per second:    237.42 [#/sec] (mean)
Enter fullscreen mode Exit fullscreen mode

Đây là throughput chính. Con số càng cao càng tốt, nhưng chỉ có ý nghĩa khi lỗi thấp hoặc bằng 0.

4. Time per request 

Time per request:       210.598 [ms] (mean)
Time per request:       4.212 [ms] (mean, across all concurrent requests)
Enter fullscreen mode Exit fullscreen mode

Dòng đầu tiên là latency trung bình mà một client cảm nhận. Đây là số bạn thường nên quan tâm.

Dòng thứ hai là thời gian trung bình trên toàn bộ request đồng thời. Nó hữu ích cho phân tích throughput, nhưng không đại diện trực tiếp cho trải nghiệm của một user.

5. Percentile latency 

Percentage of the requests served within a certain time (ms)
  50%    201
  90%    268
  95%    291
  99%    324
Enter fullscreen mode Exit fullscreen mode

Đây thường là phần quan trọng nhất.

  • 50%: median latency.
  • 95%: 95% request hoàn thành trong thời gian này.
  • 99%: latency phần đuôi, nơi user dễ cảm nhận chậm nhất.

Trong ví dụ trên:

  • Một nửa request hoàn thành trong 201ms.
  • 95% request hoàn thành trong 291ms.
  • 99% request hoàn thành trong 324ms.

Khi benchmark API, đừng chỉ nhìn average. Hãy theo dõi P95 và P99.

Xuất kết quả ra file

Để xuất dữ liệu percentile ra CSV:

ab -n 1000 -c 50 -k \
  -e results.csv \
  https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Để xuất file thân thiện với gnuplot:

ab -n 1000 -c 50 -k \
  -g results.tsv \
  https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Bạn có thể dùng các file này để tạo biểu đồ latency hoặc so sánh nhiều lần chạy.

Quy trình benchmark thực tế

Một cách chạy đơn giản:

Bước 1: Kiểm tra endpoint hoạt động bình thường 

curl -i https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Đảm bảo response đúng trước khi benchmark.

Bước 2: Chạy baseline với concurrency thấp 

ab -n 1000 -c 10 -k https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Ghi lại:

  • Requests per second
  • Failed requests
  • Non-2xx responses
  • P95
  • P99

Bước 3: Tăng concurrency dần 

ab -n 1000 -c 25 -k https://api.example.com/v1/users
ab -n 1000 -c 50 -k https://api.example.com/v1/users
ab -n 1000 -c 100 -k https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Quan sát điểm mà:

  • Requests per second không tăng nữa.
  • P95/P99 tăng mạnh.
  • Failed requests hoặc Non-2xx responses xuất hiện.

Đó thường là vùng endpoint bắt đầu bão hòa.

Bước 4: Test lại với thời gian cố định 

ab -t 60 -c 50 -k https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Dùng cách này để xem endpoint có giữ ổn định trong 60 giây không.

Khi nào ab không còn phù hợp?

ab hữu ích, nhưng không nên dùng cho mọi loại load test.

1. Chỉ test một URL mỗi lần

ab không mô phỏng được user journey nhiều bước như:

  1. Login.
  2. Lấy token.
  3. Tạo resource.
  4. Đọc resource.
  5. Cập nhật resource.

Nếu cần flow như vậy, bạn cần công cụ hỗ trợ kịch bản.

2. Không kiểm tra tính đúng đắn của response

ab chủ yếu kiểm tra status code và byte length. Nó không biết JSON response có đúng schema không.

Một response sai cấu trúc vẫn có thể được tính là thành công nếu status code và độ dài hợp lệ.

3. Không hỗ trợ HTTP/2

Theo tài liệu chính thức, ab không triển khai đầy đủ HTTP/1.x và không hỗ trợ HTTP/2. Nếu hệ thống của bạn phụ thuộc vào HTTP/2, kết quả từ ab có thể không phản ánh đúng production.

4. Chỉ tạo tải từ một máy

ab chạy từ một máy và một process. Ở concurrency cao, bạn có thể đang đo giới hạn của máy client thay vì server.

Nếu cần tải phân tán, hãy dùng công cụ chuyên dụng.

ab không tệ. Nó chỉ có phạm vi rõ ràng: benchmark nhanh một endpoint. Khi cần kịch bản nhiều bước, tải phân tán hoặc HTTP/2, hãy cân nhắc công cụ khác. JMeter hỗ trợ kịch bản nhiều bước và chạy phân tán. Bạn cũng có thể xem danh sách công cụ kiểm thử tải API để so sánh lựa chọn.

Kết hợp kiểm thử chức năng với benchmark tải

Throughput chỉ là một phần. Trước khi đo tải, bạn cần chắc chắn endpoint trả đúng dữ liệu trong điều kiện bình thường.

Đó là phần kiểm thử chức năng và kiểm thử hợp đồng. ab không làm việc này.

Apidog có thể dùng bên cạnh ab để:

  • Tạo test scenario cho API.
  • Xâu chuỗi nhiều request thành flow.
  • Thêm assertion trực quan.
  • Validate response theo schema.
  • Lưu scenario và chạy lại trong CI.

Cài Apidog CLI bằng Node:

npm install -g apidog-cli
Enter fullscreen mode Exit fullscreen mode

Chạy một scenario hoặc suite đã lưu:

apidog run \
  --access-token "$APIDOG_ACCESS_TOKEN" \
  -t <scenarioOrSuiteId> \
  -e <environmentId> \
  -r cli,html,junit
Enter fullscreen mode Exit fullscreen mode

Ý nghĩa các flag:

  • -t: ID của scenario, folder hoặc suite.
  • -e: ID môi trường.
  • -r: reporter, ví dụ cli, html, json, junit.
  • -d hoặc --iteration-data: dữ liệu cho test data-driven.

Một setup thực tế:

  1. Chạy test Apidog để xác minh API đúng.
  2. Chạy ab để đo endpoint có đủ nhanh và chịu tải được không.
  3. Đưa cả hai vào CI nếu phù hợp.

Xem thêm hướng dẫn kiểm thử hiệu suất Apidog và hướng dẫn kiểm thử hiệu suất API.

Câu hỏi thường gặp

ApacheBench chỉ dùng cho Apache Server?

Không. Dù tên là ApacheBench, ab gửi HTTP/HTTPS request đến bất kỳ server nào: Nginx, Node.js, Go, Python, Java hoặc server HTTP khác. Nó chỉ được đóng gói cùng Apache HTTP Server.

Nên chọn concurrency và số request như thế nào?

Bắt đầu thấp rồi tăng dần:

ab -n 1000 -c 10 -k https://api.example.com/v1/users
ab -n 1000 -c 25 -k https://api.example.com/v1/users
ab -n 1000 -c 50 -k https://api.example.com/v1/users
ab -n 1000 -c 100 -k https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Tìm điểm mà throughput ngừng tăng, P95/P99 tăng mạnh hoặc lỗi bắt đầu xuất hiện. Đừng chọn concurrency lớn chỉ vì số tròn; hãy bám theo traffic thực tế dự kiến.

Vì sao Failed requests cao dù API vẫn hoạt động?

ab có thể xem request là failed nếu độ dài response khác nhau giữa các lần gọi. Với JSON động, điều này khá bình thường.

Dùng -l để bỏ qua khác biệt độ dài:

ab -n 1000 -c 50 -k -l https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Sau đó kiểm tra thêm Non-2xx responses để biết có lỗi thật không.

ab có test endpoint cần token đăng nhập không?

Có, nếu bạn đã có token:

ab -n 500 -c 25 -k \
  -H "Authorization: Bearer YOUR_TOKEN" \
  https://api.example.com/v1/users
Enter fullscreen mode Exit fullscreen mode

Nhưng ab không tự chạy flow login để lấy token mới rồi dùng token đó. Với flow nhiều bước, hãy dùng công cụ dựa trên scenario như Apidog.

ab có hỗ trợ HTTP/2 không?

Không. ab dùng HTTP/1.x và không hỗ trợ HTTP/2. Nếu hành vi HTTP/2 quan trọng với hệ thống của bạn, hãy dùng công cụ benchmark có hỗ trợ HTTP/2.

Top comments (0)