Bạn đã viết một điểm cuối HTTP. Nó hoạt động khi bạn gọi nó một lần từ Postman. Nhưng điều gì sẽ xảy ra khi 200 client gọi nó cùng lúc? Bạn cần các con số: số lượng yêu cầu mỗi giây, phân vị độ trễ và số lượng phản hồi trả về với trạng thái không phải 2xx. autocannon cung cấp cho bạn những con số đó từ terminal của bạn chỉ trong khoảng mười giây.
autocannon là một công cụ kiểm tra hiệu năng HTTP/1.1 được viết bằng Node.js. Nó tạo ra một lượng yêu cầu có kiểm soát đến một URL và báo cáo thông lượng cùng độ trễ. Hướng dẫn này sẽ hướng dẫn bạn cách cài đặt, một lần chạy cơ bản, mọi cờ (flag) bạn sẽ thực sự sử dụng, cách đọc kết quả đầu ra và cách điều khiển autocannon từ một script Node. Nó cũng vạch ra một ranh giới rõ ràng giữa những gì một bài kiểm tra tải có thể cho bạn biết và những gì nó không thể, để bạn biết khi nào nên dùng thử nghiệm chức năng và hợp đồng thay thế.
autocannon là gì
autocannon mở một số lượng kết nối đồng thời cố định đến một URL và tiếp tục gửi yêu cầu trong một khoảng thời gian nhất định (hoặc một số lượng yêu cầu nhất định). Trong khi chạy, nó lấy mẫu độ trễ và đếm các phản hồi. Khi kết thúc, nó in ra một bảng phân vị độ trễ và một bản tóm tắt tổng số yêu cầu và byte đã đọc.
Nó đo lường một điều: máy chủ của bạn xử lý được bao nhiêu tải và nó phản hồi nhanh như thế nào dưới tải đó. Nó không kiểm tra xem nội dung phản hồi có chính xác không, API của bạn có khớp với thông số kỹ thuật OpenAPI không, hay quy trình làm việc nhiều bước có trả về dữ liệu đúng ở mỗi bước không. Hãy ghi nhớ sự khác biệt đó. Nó định hình vị trí của autocannon trong bộ công cụ kiểm thử của bạn, được đề cập ở gần cuối.
Nếu bạn đã từng sử dụng wrk hoặc Apache Bench, autocannon lấp đầy cùng một vị trí với cài đặt Node-native và API lập trình mà bạn có thể gọi từ JavaScript.
Cài đặt
autocannon được phân phối dưới dạng gói npm. Cài đặt nó toàn cầu để có thể sử dụng lệnh autocannon ở bất cứ đâu:
npm i autocannon -g
Bạn cần cài đặt Node.js trước. Nếu bạn không muốn cài đặt toàn cầu, hãy chạy nó theo yêu cầu bằng npx:
npx autocannon http://localhost:3000
Hoặc thêm nó vào một dự án dưới dạng dev dependency khi bạn có kế hoạch viết script cho nó:
npm i autocannon --save-dev
Xác minh cài đặt:
autocannon --version
Chạy cơ bản
Hình thức đơn giản nhất là lệnh cộng với một URL. Điều này chạy bài kiểm tra hiệu năng mặc định: 10 kết nối trong 10 giây.
autocannon http://localhost:3000
Điều chỉnh với ba cờ mà bạn sẽ sử dụng liên tục. -c đặt số lượng kết nối đồng thời, -d đặt thời lượng tính bằng giây và -p đặt pipelining (số lượng yêu cầu mà mỗi kết nối gửi trước khi chờ phản hồi).
autocannon -c 100 -d 30 -p 10 http://localhost:3000
Lệnh đó mở 100 kết nối, chạy trong 30 giây và thực hiện pipelining 10 yêu cầu cho mỗi kết nối. Số lượng kết nối và pipelining cao hơn sẽ đẩy tải nặng hơn, đây là cách bạn tìm ra điểm mà độ trễ bắt đầu tăng lên.
Để gửi một số lượng yêu cầu cố định thay vì chạy trong một khoảng thời gian, hãy sử dụng -a (amount):
autocannon -c 10 -a 10000 http://localhost:3000
Lệnh đó sẽ dừng sau 10.000 yêu cầu bất kể thời gian.
Yêu cầu POST, tiêu đề và nội dung
Thay đổi phương thức bằng -m, thêm tiêu đề bằng -H và truyền nội dung yêu cầu bằng -b. Đây là một yêu cầu POST đến một điểm cuối JSON:
autocannon -c 50 -d 20 \
-m POST \
-H 'Content-Type=application/json' \
-H 'Authorization=Bearer YOUR_TOKEN' \
-b '{"name":"load-test","active":true}' \
http://localhost:3000/api/users
Lưu ý định dạng tiêu đề: -H 'Khóa=Giá trị', và bạn lặp lại -H cho mỗi tiêu đề. Nếu nội dung của bạn lớn hoặc nằm trong một tệp, hãy sử dụng -i để đọc nó từ đĩa thay vì đưa trực tiếp vào:
autocannon -m POST -H 'Content-Type=application/json' -i payload.json http://localhost:3000/api/users
Giới hạn tốc độ kiểm thử
Theo mặc định, autocannon gửi yêu cầu nhanh nhất có thể. Đôi khi bạn muốn một tốc độ ổn định, thực tế hơn là một làn sóng áp lực tối đa. -R giới hạn tổng số yêu cầu mỗi giây trên tất cả các kết nối:
autocannon -c 50 -R 500 -d 60 http://localhost:3000
Lệnh đó giữ bài kiểm thử ở mức 500 yêu cầu mỗi giây trong 60 giây. Điều này hữu ích khi bạn muốn đo độ trễ ở mức tải dự kiến trong sản xuất thay vì tại điểm phá vỡ.
Khởi động và các luồng worker
Hai cờ nữa giúp ích trong các lần chạy nặng hơn. -W (warmup) gửi traffic trong một khoảng thời gian ngắn trước khi autocannon bắt đầu lấy mẫu, để các con số đầu tiên của bạn không bị sai lệch bởi cache lạnh hoặc JIT chưa được khởi động. -w (workers) phân tán tải trên nhiều luồng worker của Node, điều này quan trọng khi một luồng đơn không thể tạo đủ yêu cầu để bão hòa một máy chủ nhanh:
autocannon -c 200 -d 30 -w 4 http://localhost:3000
Chỉ sử dụng -w khi bạn đã xác nhận rằng chính trình tạo tải đang là nút thắt cổ chai. Nếu độ trễ trông đáng ngờ khi bạn tăng -c, trình tạo của bạn có thể đã đạt mức tối đa và việc thêm worker sẽ cho bạn một cái nhìn chân thực hơn về giới hạn của máy chủ.
Đọc kết quả
Khi một lần chạy kết thúc, autocannon in ra một bảng độ trễ và một dòng tóm tắt. Một ví dụ đã được cắt bớt:
Running 10s test @ http://localhost:3000
10 connections
┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬──────────┐
│ Stat │ 2.5% │ 50% │ 97.5% │ 99% │ Avg │ Stdev │ Max │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼──────────┤
│ Latency │ 0 ms │ 1 ms │ 4 ms │ 6 ms │ 1.2 ms │ 0.9 ms │ 24.1 ms │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴──────────┘
251k requests in 10.05s, 27.9 MB read
Đây là cách đọc nó:
- Các cột phân vị (2.5%, 50%, 97.5%, 99%) quan trọng hơn mức trung bình. Cột 50% là trung vị. Cột 99% cho bạn biết độ trễ mà 1 phần trăm người dùng chậm nhất của bạn gặp phải. Độ trễ đuôi là nơi các vấn đề thực sự ẩn giấu, vì vậy hãy chú ý đến các con số 97.5% và 99%.
- Avg và Stdev cho bạn giá trị trung bình và mức độ phân tán của độ trễ. Độ lệch chuẩn cao có nghĩa là thời gian phản hồi không nhất quán.
- Dòng tóm tắt (“251k requests in 10.05s”) là thông lượng của bạn. Chia số yêu cầu cho số giây để có số yêu cầu mỗi giây.
Hai cờ làm cho đầu ra hữu ích hơn. Thêm -l để in toàn bộ các phân vị độ trễ (bao gồm p99.9 trở lên), và thêm --renderStatusCodes để xem chi tiết theo mã trạng thái để bạn có thể phát hiện một loạt 500 ẩn sau một con số thông lượng tốt:
autocannon -c 100 -d 20 -l --renderStatusCodes http://localhost:3000
Theo dõi các lỗi, thời gian chờ và số lượng không phải 2xx. Một máy chủ có thể đạt tốc độ yêu cầu cao trong khi âm thầm trả về lỗi. Nếu số lượng không phải 2xx không bằng 0, con số thông lượng của bạn đang đo lường các thất bại, không phải thành công.
Sử dụng lập trình trong một script
autocannon cung cấp một API Node.js, vì vậy bạn có thể chạy các bài kiểm tra hiệu năng từ một script và xử lý kết quả. Đây là nơi nó phát huy tác dụng trong tự động hóa: chạy một bài kiểm thử, đọc các con số và làm cho bản dựng thất bại nếu độ trễ vượt quá ngưỡng.
Cuộc gọi cốt lõi nhận một đối tượng tùy chọn và trả về một promise:
const autocannon = require('autocannon')
async function run() {
const result = await autocannon({
url: 'http://localhost:3000',
connections: 100,
duration: 20,
pipelining: 1
})
console.log(`Độ trễ trung bình: ${result.latency.average} ms`)
console.log(`Yêu cầu/giây: ${result.requests.average}`)
console.log(`Không phải 2xx: ${result.non2xx}`)
}
run()
Đối tượng result chứa các biểu đồ cho latency, requests và throughput, mỗi biểu đồ có các trường average, min, max và phân vị như p99. Nó cũng chứa số lượng errors, timeouts và non2xx.
Để biến điều đó thành một cổng, hãy thêm một kiểm tra thoát không phải 0 khi một ngân sách bị vượt quá:
const autocannon = require('autocannon')
const P99_BUDGET_MS = 250
async function run() {
const result = await autocannon({
url: 'http://localhost:3000/api/health',
connections: 100,
duration: 30
})
const p99 = result.latency.p99
console.log(`Độ trễ p99: ${p99} ms (ngân sách ${P99_BUDGET_MS} ms)`)
if (p99 > P99_BUDGET_MS || result.non2xx > 0) {
console.error('Ngân sách hiệu suất đã bị vượt quá')
process.exit(1)
}
}
run()
Nếu bạn muốn thanh tiến trình trực tiếp và bảng kết quả mà CLI hiển thị, hãy truyền thể hiện đó đến autocannon.track:
const autocannon = require('autocannon')
const instance = autocannon({
url: 'http://localhost:3000',
connections: 10,
duration: 10
}, console.log)
autocannon.track(instance, { renderProgressBar: true })
process.once('SIGINT', () => instance.stop())
Đối với một kịch bản nhiều yêu cầu, hãy truyền một mảng requests để mỗi kết nối lặp qua một số lệnh gọi:
autocannon({
url: 'http://localhost:3000',
connections: 20,
duration: 15,
requests: [
{ method: 'GET', path: '/api/users' },
{ method: 'POST', path: '/api/data', body: '{"x":1}',
headers: { 'Content-Type': 'application/json' } }
]
}, console.log)
autocannon so với wrk và ab
Cả ba đều trả lời cùng một câu hỏi (nhanh đến mức nào, dưới bao nhiêu tải), và lựa chọn đúng đắn phụ thuộc vào ngăn xếp công nghệ của bạn.
- Apache Bench (ab) là công cụ nhị phân đơn cổ điển. Nó có ở khắp mọi nơi và đơn giản, nhưng đơn luồng và đã lỗi thời.
- wrk nhanh và có thể tạo tải nặng với kịch bản Lua cho các yêu cầu tùy chỉnh. Nó là một công cụ C được biên dịch, vì vậy bạn cài đặt nó bên ngoài npm.
- autocannon khớp với wrk về thông lượng cho hầu hết các khối lượng công việc và thắng thế về tính dễ sử dụng nếu bạn đã quen với Node:
npm iđể cài đặt, API JavaScript để viết script và hỗ trợ pipelining, tệp HAR và các kịch bản theo yêu cầu ngay từ đầu.
Nếu Node là runtime của bạn, autocannon là lựa chọn ít gặp trở ngại nhất. Thích công cụ Python? Xem cách kiểm tra tải mà không cần Python. Muốn một tùy chọn có thể viết script với bộ tính năng lớn? So sánh kiểm tra tải k6.
Kiểm thử chức năng và Apidog phù hợp ở đâu
autocannon cho bạn biết điểm cuối của bạn phục vụ 12.000 yêu cầu mỗi giây với p99 là 40 ms. Nó không cho bạn biết điểm cuối có trả về dữ liệu đúng không. Một bài kiểm tra tải có thể vượt qua một cách xuất sắc trong khi API trả về JSON bị định dạng sai, bỏ qua tiêu đề xác thực hoặc lệch khỏi hợp đồng OpenAPI của nó. Thông lượng không phải là tính đúng đắn.
Đó là khoảng trống mà kiểm thử chức năng và hợp đồng lấp đầy, và đó là nơi Apidog bổ sung cho một công cụ tải chứ không phải thay thế nó. Apidog không phải là một trình tạo tải. Nó chạy các kịch bản kiểm thử đã lưu với các xác nhận về mã trạng thái, lược đồ phản hồi và giá trị trên các luồng nhiều bước, vì vậy bạn có thể phát hiện các lỗi mà một bài kiểm tra hiệu năng không thể nhìn thấy.
Bạn chạy cả hai trong CI, và chúng trả lời các câu hỏi khác nhau. Sử dụng autocannon (hoặc wrk) để trả lời "nó có đủ nhanh dưới tải không?" Sử dụng Apidog CLI để trả lời "nó có đúng không?" Apidog CLI là headless và chạy các kịch bản hoặc bộ kiểm thử đã lưu từ bất kỳ bước CI nào có Node:
npm install -g apidog-cli
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t <scenarioOrSuiteId> \
-e <environmentId> \
-r cli,html,junit
Cờ -t nhắm mục tiêu một kịch bản, thư mục hoặc bộ đã lưu theo ID, -e chọn môi trường và -r chọn một hoặc nhiều trình báo cáo (cli, html, json, junit) để lần chạy tạo ra các hiện vật mà pipeline của bạn có thể lưu trữ. Để biết hướng dẫn đầy đủ, hãy xem cách chạy kiểm thử API từ Apidog CLI, pipeline CI/CD sao chép-dán và workflow GitHub Actions.
Một pipeline lành mạnh chạy kiểm tra chức năng và hợp đồng trên mỗi lần đẩy (nó có hoạt động không?), sau đó chạy một bài kiểm tra tải trước khi phát hành (nó có giữ được không?). autocannon chịu trách nhiệm câu hỏi thứ hai. Apidog chịu trách nhiệm câu hỏi thứ nhất.
Câu hỏi thường gặp
autocannon có chính xác cho kiểm thử tải sản xuất không?
autocannon tạo ra các con số thông lượng và độ trễ đáng tin cậy cho các điểm cuối HTTP/1.1, và khi bạn đặt tốc độ mục tiêu với -R, nó sẽ sửa lỗi bỏ qua điều phối (coordinated omission), một bước mà nhiều công cụ đơn giản hơn bỏ qua. Để có kết quả chính xác, hãy chạy nó từ một máy gần máy chủ của bạn (nếu không thì độ trễ mạng sẽ chiếm ưu thế) và sử dụng đủ kết nối để bão hòa điểm cuối. Chạy nó chống lại một môi trường thử nghiệm (staging) phản ánh sản xuất, không phải chống lại máy chủ dev trên máy tính xách tay của bạn.
autocannon có hỗ trợ HTTP/2 hoặc WebSockets không?
Không. autocannon kiểm tra hiệu năng HTTP/1.1. Đối với kiểm thử tải HTTP/2 hoặc WebSocket, bạn cần một công cụ khác. Đây là giới hạn chính cần kiểm tra trước khi bạn chọn nó.
Tôi nên sử dụng bao nhiêu kết nối?
Bắt đầu ở mức mặc định là 10, sau đó tăng -c cho đến khi số yêu cầu mỗi giây ngừng tăng và độ trễ bắt đầu tăng. Điểm uốn đó gần đúng là dung lượng của máy chủ của bạn. Đẩy quá xa nó sẽ đo lường giới hạn của trình tạo tải của bạn hơn là của máy chủ của bạn.
Tôi có thể chạy autocannon trong CI không?
Có. API lập trình được xây dựng cho mục đích đó: chạy một bài kiểm tra hiệu năng, đọc result.latency.p99 và result.non2xx, và gọi process.exit(1) khi ngân sách bị vượt quá. Điều đó biến một bài kiểm tra hiệu năng thành một cổng đạt/trượt mà bạn có thể kết nối vào bất kỳ bước CI nào có hỗ trợ Node.
Sự khác biệt giữa -a và -d là gì?
-d chạy trong một số giây nhất định. -a chạy cho đến khi một số yêu cầu hoàn thành, sau đó dừng. Sử dụng -d cho một bài kiểm tra tải trạng thái ổn định và -a khi bạn muốn gửi một số lượng yêu cầu chính xác.