Bạn muốn biết điều gì sẽ xảy ra với API của mình khi 80 người cùng lúc nhấn nút thanh toán. Vì vậy, bạn mở Locust, và điều đầu tiên nó yêu cầu bạn làm là viết một lớp Python. Định nghĩa một HttpUser. Trang trí các phương thức bằng @task. Xây dựng một locustfile.py, thiết lập một môi trường ảo, ghim một vài phụ thuộc, và sau đó tìm hiểu lý do tại sao mã thông báo xác thực của bạn không được sử dụng lại giữa các yêu cầu. Tất cả những điều đó không phải là bài kiểm tra. Đó là chi phí ban đầu trước khi bài kiểm tra bắt đầu.
Locust là một công cụ tốt, và thiết kế ưu tiên mã nguồn là điểm mấu chốt của nó. Nhưng nếu mục tiêu của bạn là một câu trả lời thẳng thắn cho câu hỏi “điểm cuối đăng nhập của tôi có chịu được 100 người dùng đồng thời không,” thì việc viết và duy trì một khung Python là một công việc tốn kém chỉ để có được một con số. Có một con đường nhanh hơn khi các yêu cầu API bạn muốn kiểm tra tải đã tồn tại trong một máy khách API. Với Apidog, bạn chỉ cần hướng một bài kiểm tra hiệu suất vào một kịch bản kiểm tra hiện có, đặt số lượng người dùng ảo và thời lượng, sau đó đọc thông lượng, thời gian phản hồi và tỷ lệ lỗi từ biểu đồ trực tiếp. Không cần locustfile, không cần pip install, không cần Python chút nào.
Điều mà Locust thực sự làm tốt
Locust là một công cụ kiểm thử tải mã nguồn mở được viết bằng Python, và nó thực hiện tốt những gì nó được xây dựng để làm. Bạn mô tả hành vi người dùng dưới dạng mã. Một người dùng ảo là một lớp Python, và những việc người dùng đó làm là các phương thức bạn gắn thẻ là nhiệm vụ. Đây là hình dạng chuẩn của một locustfile.py:
from locust import HttpUser, task, between
class CheckoutUser(HttpUser):
wait_time = between(1, 3)
@task(3)
def browse_products(self):
self.client.get("/api/products")
@task(1)
def add_to_cart(self):
self.client.post("/api/cart", json={"sku": "AK-204", "qty": 1})
Bạn chạy nó với locust -f locustfile.py, mở giao diện người dùng web tại localhost:8089, đặt số lượng người dùng và tốc độ tạo, sau đó xem các con số tăng lên. Bởi vì hành vi được mô tả bằng mã, bạn có được sức mạnh biểu đạt thực sự. Logic có điều kiện, phân phối nhiệm vụ có trọng số, hành trình người dùng tuần tự, các client tùy chỉnh cho các giao thức ngoài HTTP, trạng thái chia sẻ giữa các yêu cầu. Trọng số @task(3) so với @task(1) ở trên có nghĩa là việc duyệt sản phẩm xảy ra thường xuyên gấp ba lần so với việc thêm vào giỏ hàng, đây là loại chủ nghĩa hiện thực mà một danh sách yêu cầu đơn giản không thể nắm bắt được.
Locust cũng có khả năng mở rộng theo chiều ngang. Bạn có thể chạy nó phân tán trên nhiều quy trình hoặc máy chủ worker và một master duy nhất sẽ điều phối chúng, giúp bạn vượt qua giới hạn tạo tải của một máy đơn lẻ. Về cơ bản, nó được điều khiển bằng sự kiện, vì vậy mỗi worker có thể xử lý hàng nghìn người dùng đồng thời mà không tốn bộ nhớ quá nhiều (như khi mỗi người dùng có một luồng riêng). Đối với một nhóm đã quen với Python, coi các bài kiểm thử tải của mình là mã được kiểm soát phiên bản và cần mô hình hóa hành vi người dùng nhiều bước phức tạp, Locust là một lựa chọn mạnh mẽ. Không có điều gì trong số đó là phải tranh cãi.
Cái giá phải trả là mã. Mỗi bài kiểm tra là một chương trình bạn viết, gỡ lỗi và duy trì. Nếu API của bạn thay đổi, locustfile cũng thay đổi. Nếu một kỹ sư mới cần chạy bài kiểm tra, họ cần một môi trường Python phù hợp. Và nếu bạn chưa viết Python, bản thân ngôn ngữ này trở thành một điều kiện tiên quyết để trả lời một câu hỏi không liên quan gì đến Python.
Khi mô hình ưu tiên mã nguồn trở thành rào cản
Rào cản xuất hiện ở ba điểm.
Đầu tiên, thiết lập. Trước khi bạn đo lường bất cứ điều gì, bạn cài đặt Python, tạo một môi trường ảo, pip install locust, và viết khung kiểm thử. Đối với một kiểm tra nhanh “điểm cuối này có thể chịu được 50 người dùng không,” đó là quá nhiều công đoạn chuẩn bị hơn là nội dung thực tế.
Thứ hai, trùng lặp. Bạn có thể đã định nghĩa các yêu cầu này ở đâu đó rồi. Có thể trong Postman, có thể trong một tệp .http, hoặc có thể trong một ứng dụng khách API mà nhóm của bạn sử dụng hàng ngày. locustfile mô tả lại các yêu cầu đã tồn tại, bao gồm luồng xác thực, tiêu đề, và nội dung yêu cầu. Giờ đây, bạn duy trì hai bản sao của cùng một kiến thức API, và chúng có thể bị sai lệch.
Thứ ba, những người cần câu trả lời. Một kỹ sư QA, một quản lý sản phẩm đang lo lắng về một buổi ra mắt, hoặc một nhà phát triển frontend chỉ muốn biết liệu API có chịu được lượng truy cập từ email marketing hay không – tất cả đều cần kết quả kiểm thử tải. Họ không nhất thiết phải đọc hoặc viết Python để xứng đáng có được nó. Khi bài kiểm thử bị khóa sau một locustfile, câu trả lời cũng bị khóa sau một bộ kỹ năng.
Nếu các bài kiểm thử tải của bạn thực sự cần logic phân nhánh và các client giao thức tùy chỉnh, thì rào cản đó đáng để chấp nhận và Locust là công cụ phù hợp. Đối với trường hợp phổ biến là “chạy các yêu cầu API thực của tôi dưới tải đồng thời và cho tôi xem các con số,” thì đáng để tự hỏi liệu lớp Python có mang lại lợi ích gì cho bạn hay không.
Cách tiếp cận của Apidog: kiểm thử tải các yêu cầu bạn đã có
Apidog tiếp cận việc kiểm thử tải theo hướng khác. Bạn không viết một tập lệnh mô tả các yêu cầu. Bạn lấy các yêu cầu bạn đã xây dựng và chạy chúng dưới tải. Đơn vị của một bài kiểm thử tải là một kịch bản kiểm thử, đây chỉ là một tập hợp có thứ tự các yêu cầu API với môi trường, biến số và các xác nhận đã được đính kèm. Nếu bạn đã sử dụng Apidog để kiểm thử hoặc gỡ lỗi một điểm cuối, yêu cầu đó đã có sẵn. Bài kiểm thử hiệu suất sẽ sử dụng lại nó.
Đây là quy trình đầy đủ.
- Mở kịch bản kiểm thử mà bạn muốn kiểm thử tải. Đây là kịch bản tương tự mà bạn sẽ chạy như một bài kiểm thử chức năng thông thường, với cùng các yêu cầu và cùng các biến môi trường.
- Chọn chạy nó như một bài kiểm thử hiệu suất thay vì một lần chạy duy nhất.
- Đặt số lượng người dùng ảo. Apidog hỗ trợ tới 100 người dùng ảo, mỗi người dùng sẽ lặp lại mọi yêu cầu trong kịch bản song song trong suốt bài kiểm thử.
- Đặt thời lượng kiểm thử. Đây là khoảng thời gian mà người dùng ảo sẽ tiếp tục lặp lại.
- Đặt thời lượng tăng dần (ramp-up duration) nếu bạn muốn tăng tải từ từ. Trong X phút đầu tiên, Apidog sẽ đưa người dùng vào trực tuyến tăng dần thay vì tất cả cùng một lúc; đặt nó bằng 0 và mọi người dùng ảo sẽ bắt đầu ngay lập tức.
- Nếu kịch bản của bạn được điều khiển bằng dữ liệu, hãy chọn một chế độ khớp. “Random Match” (Khớp Ngẫu nhiên) có nghĩa là mỗi người dùng ảo sẽ lấy một hàng ngẫu nhiên từ dữ liệu kiểm thử của bạn trong mỗi vòng lặp; “Sequential Match” (Khớp Tuần tự) sẽ duyệt qua các hàng theo thứ tự.
- Bắt đầu kiểm thử và theo dõi bảng điều khiển trực tiếp.
Biểu đồ cập nhật theo thời gian thực. Đối với mỗi API trong kịch bản, bạn sẽ nhận được Tổng số yêu cầu, Thông lượng trung bình, Thời gian phản hồi trung bình, Thời gian phản hồi tối đa và tối thiểu, và Lỗi. Di chuột qua biểu đồ để xem các con số cho một khoảng thời gian cụ thể. Một tab “Lỗi” sẽ phân tích các yêu cầu thất bại để bạn có thể thấy điểm cuối nào bắt đầu gặp sự cố và khi nào. Khi quá trình chạy kết thúc, tab “Báo cáo kiểm thử” sẽ lưu giữ lịch sử để bạn có thể so sánh kết quả chạy hôm nay với kết quả của tuần trước sau khi bạn triển khai thay đổi.
Toàn bộ vấn đề là không cần viết locustfile và không cần quản lý môi trường Python. Cùng một yêu cầu đã vượt qua bài kiểm thử chức năng của bạn chính là yêu cầu tạo tải. Đó là sự khác biệt giữa việc mô tả một bài kiểm thử tải và việc chạy một bài kiểm thử tải. Apidog là một nền tảng API tất cả trong một, vì vậy việc thiết kế, gỡ lỗi, kiểm thử chức năng và kiểm thử tải của một điểm cuối đều diễn ra dựa trên một định nghĩa duy nhất của điểm cuối đó.
So sánh cụ thể
Giả sử bạn muốn xác nhận một điểm cuối đăng nhập có thể xử lý 100 người dùng đồng thời trong hai phút, với thời gian tăng tải 30 giây.
Trong Locust, bạn viết một lớp người dùng với một tác vụ gửi thông tin đăng nhập, xử lý mã thông báo mà phản hồi trả về, lưu trữ nó cho bất kỳ lệnh gọi tiếp theo nào, lưu tệp, khởi động locust -f login_test.py, mở giao diện người dùng web và nhập 100 người dùng, tốc độ tạo và thời gian chạy. Nếu việc xử lý mã thông báo sai, bạn gỡ lỗi Python trước khi gỡ lỗi API của mình.
Trong Apidog, bạn mở kịch bản kiểm thử đăng nhập đã xây dựng sẵn, chuyển nó thành một bài kiểm thử hiệu suất, nhập 100 cho người dùng ảo, 2 phút cho thời lượng, 30 giây cho thời gian tăng tải, và khởi động. Xác thực đã hoạt động trong bài kiểm thử chức năng của bạn vẫn hoạt động, vì đó là cùng một kịch bản. Bạn đọc đường cong thời gian phản hồi và tỷ lệ lỗi khi chúng xảy ra.
Cả hai đều đi đến cùng một loại câu trả lời. Một yêu cầu bạn viết và duy trì một chương trình trước. Cái kia sử dụng lại những gì bạn đã có. Đối với các hành trình người dùng phức tạp, được mô hình hóa bằng mã, chương trình đó đáng giá. Đối với câu hỏi “điểm cuối của tôi có nhanh và ổn định dưới tải không,” việc tái sử dụng giúp tiết kiệm thời gian.
Những hạn chế trung thực của cả hai bên
Hãy rõ ràng về những đánh đổi, bởi vì chọn sai công cụ sẽ lãng phí một ngày của bạn theo bất kỳ cách nào.
Kiểm thử hiệu suất của Apidog đạt tối đa 100 người dùng ảo từ một lần chạy, và tải được tạo ra từ máy tính của bạn đang chạy ứng dụng. Nếu bạn cần mô phỏng hàng chục nghìn người dùng hoặc tạo tải từ nhiều khu vực địa lý cùng một lúc, thì điều đó vượt quá khả năng của kiểm thử hiệu suất trong ứng dụng, và một thiết lập phân tán như các worker của Locust hoặc một cụm tạo tải chuyên dụng là lựa chọn đúng đắn. Apidog cũng ghi lại các yêu cầu thất bại theo thống kê chứ không thu thập toàn bộ nội dung yêu cầu và phản hồi cho mọi lỗi, vì vậy việc gỡ lỗi pháp y sâu sắc cho một lệnh gọi thất bại cụ thể trong quá trình tải không phải là thế mạnh của nó.
Sự đánh đổi của Locust là điều mà toàn bộ bài viết này nói đến. Sức mạnh đến từ mã, và mã là một chi phí cố định. Bạn duy trì một locustfile cho mỗi kịch bản, giữ một môi trường Python và chấp nhận rằng bất kỳ ai muốn chạy bài kiểm thử đều cần đọc Python để hiểu nó. Đối với số lượng người dùng ảo rất cao và logic giao thức tùy chỉnh, chi phí đó mang lại cho bạn giá trị thực. Đối với việc kiểm tra tải API hàng ngày, đó là chi phí phát sinh.
Một quy tắc hợp lý: nếu bạn có thể mô tả bài kiểm thử là “chạy các yêu cầu này với mức độ đồng thời này trong khoảng thời gian này,” hãy sử dụng kiểm thử hiệu suất trong ứng dụng. Nếu bạn cần phân nhánh có điều kiện, biểu đồ tác vụ có trọng số, client tùy chỉnh hoặc số lượng người dùng lên đến sáu chữ số, hãy sử dụng mã. Để có cái nhìn tổng quan rộng hơn về nơi mỗi lựa chọn phù hợp, hãy xem tổng hợp của chúng tôi về các công cụ kiểm thử tải hàng đầu và so sánh công cụ kiểm thử tải dành riêng cho API.
Đọc các con số bạn nhận được
Một bài kiểm thử tải chỉ hữu ích nếu bạn biết ý nghĩa của đầu ra. Bốn chỉ số mang trọng lượng lớn nhất.
Thông lượng (RPS/TPS) là số yêu cầu hoặc giao dịch mỗi giây, tốc độ mà API của bạn thực sự phục vụ. Đó là giới hạn trên mà hệ thống của bạn có thể xử lý. Nếu thông lượng chững lại trong khi bạn tiếp tục thêm người dùng ảo, bạn đã tìm thấy một điểm bão hòa.
Thời gian phản hồi (độ trễ) là thời gian mỗi yêu cầu mất để hoàn thành. Hãy xem xét mức trung bình, nhưng chú ý kỹ hơn đến mức tối đa. Một mức trung bình tốt nhưng mức tối đa tệ có nghĩa là một số người dùng đang gặp phải trải nghiệm tồi tệ mặc dù hầu hết đều ổn. Độ trễ đuôi là nơi người dùng thực sự cảm thấy khó chịu.
Tỷ lệ lỗi là tỷ lệ các yêu cầu thất bại. Một bài kiểm thử sạch ở tải thấp nhưng bắt đầu xuất hiện lỗi 500 hoặc hết thời gian chờ khi số lượng người dùng ảo tăng lên đang cho bạn biết chính xác hệ thống bị lỗi ở đâu. Điểm mà lỗi bắt đầu xảy ra thường thú vị hơn con số thông lượng thô.
Đồng thời (Concurrency) là số lượng người dùng ảo đang hoạt động. Trong Apidog, đây là số lượng người dùng ảo bạn đặt, và thời gian tăng dần (ramp-up) kiểm soát tốc độ bạn đạt được mức đó. Việc tăng dần rất quan trọng vì một hệ thống có thể xử lý 100 người dùng nếu được tiếp cận dần dần nhưng vẫn có thể sập nếu tất cả 100 người dùng đến cùng một lúc.
Nếu bạn muốn tìm hiểu sâu hơn về điều này, hướng dẫn của chúng tôi về kiểm thử hiệu suất API sẽ đi sâu vào các chỉ số, loại kiểm thử và cách đọc các đường cong, và bài viết kiến thức cơ bản về kiểm thử hiệu suất bao gồm toàn bộ lĩnh vực rộng hơn.
Điều này phù hợp như thế nào với các công cụ bạn đã so sánh
Nếu bạn đã sử dụng JMeter, mô hình tư duy tương tự như của Apidog, vì cả hai đều cho phép bạn cấu hình một bài kiểm thử tải thông qua giao diện người dùng thay vì mã. JMeter đánh đổi điều đó bằng một kế hoạch kiểm thử dựa trên XML nặng nề hơn và một đường cong học tập dốc hơn; hướng dẫn kiểm thử tải JMeter của chúng tôi đi sâu vào chi tiết. Nếu bạn đã chạy tải thông qua bộ sưu tập của Postman, bạn đã thấy một phiên bản nhẹ hơn của cùng một ý tưởng, được đề cập trong bài kiểm thử tải với Postman, và Apidog bổ sung báo cáo hiệu suất chuyên dụng trên các yêu cầu mà bạn cũng có thể sử dụng để kiểm thử API mà không cần Postman. Apidog nằm giữa sự đơn giản không cần mã mà mọi người mong muốn và khả năng tái sử dụng yêu cầu giúp bạn không phải duy trì một khung riêng biệt.
Điểm chung giữa tất cả chúng là bài kiểm thử tải của bạn nên tái sử dụng kiến thức API bạn đã mã hóa, chứ không phải sao chép nó bằng một ngôn ngữ mới. Locust sao chép nó bằng Python vì Python là thế mạnh của nó. Apidog tái sử dụng các kịch bản của bạn vì tái sử dụng là thế mạnh của nó.
Bắt đầu
Nếu các yêu cầu của bạn đã có trong Apidog, bạn có thể chạy một bài kiểm thử hiệu suất trong vòng năm phút tới. Mở một kịch bản kiểm thử, chuyển nó thành kiểm thử hiệu suất, đặt số lượng người dùng ảo và thời lượng, sau đó bắt đầu. Nếu bạn đang chuyển từ locustfile và mệt mỏi với việc duy trì lớp Python, hãy xây dựng lại kịch bản một lần trong ứng dụng và bạn sẽ không phải viết mã kiểm thử tải nữa cho điểm cuối đó.
Tải xuống Apidog và hướng một bài kiểm thử hiệu suất vào một điểm cuối bạn đã kiểm thử. Bạn sẽ có các đường cong thông lượng, độ trễ và tỷ lệ lỗi trước khi bạn hoàn thành việc viết locustfile tương đương. Locust vẫn là câu trả lời đúng cho tải phân tán, được mô hình hóa bằng mã ở quy mô lớn. Đối với câu hỏi mà hầu hết các nhà phát triển thực sự hỏi, hãy chạy các yêu cầu bạn đã có.
Câu hỏi thường gặp
Apidog có phải là một sự thay thế hoàn hảo cho Locust không?
Không phải cho mọi công việc. Đối với việc kiểm thử tải các yêu cầu API với tối đa 100 người dùng ảo mà không cần viết mã, Apidog thay thế toàn bộ quy trình làm việc của Locust vì nó trực tiếp chạy các kịch bản kiểm thử hiện có của bạn. Đối với tải phân tán với số lượng người dùng rất cao hoặc các giao thức không phải HTTP tùy chỉnh được mô hình hóa bằng mã, Locust vẫn phù hợp hơn.
Tôi có cần viết bất kỳ mã nào để kiểm thử tải trong Apidog không?
Không. Bạn cấu hình người dùng ảo, thời lượng kiểm thử và thời gian tăng dần trong giao diện người dùng, và bài kiểm thử sẽ chạy các yêu cầu từ một kịch bản kiểm thử bạn đã xây dựng sẵn. Không có locustfile và không cần thiết lập môi trường Python.
Apidog có thể mô phỏng bao nhiêu người dùng ảo?
Lên đến 100 người dùng ảo trong một bài kiểm thử hiệu suất duy nhất. Mỗi người dùng sẽ lặp lại mọi API trong kịch bản song song trong suốt thời gian bạn đã đặt. Nếu bạn cần nhiều hơn thế hoặc tải từ nhiều khu vực, một công cụ dựa trên mã phân tán như Locust là lựa chọn đúng đắn.
Kiểm thử hiệu suất Apidog báo cáo những chỉ số nào?
Đối với mỗi API trong kịch bản, bạn sẽ nhận được Tổng số yêu cầu, Thông lượng trung bình, Thời gian phản hồi trung bình, Thời gian phản hồi tối đa và tối thiểu, và Lỗi, được cập nhật trực tiếp trên biểu đồ. Một tab Lỗi sẽ phân tích các yêu cầu thất bại, và tab Báo cáo Kiểm thử sẽ lưu giữ lịch sử chạy để bạn có thể so sánh giữa các thay đổi.
Tôi có thể kiểm thử tải với các yêu cầu được điều khiển bằng dữ liệu không?
Có. Nếu kịch bản của bạn được hỗ trợ bởi dữ liệu kiểm thử, hãy chọn “Random Match” (Khớp Ngẫu nhiên) để mỗi người dùng ảo lấy một hàng ngẫu nhiên trong mỗi vòng lặp, hoặc “Sequential Match” (Khớp Tuần tự) để duyệt qua các hàng theo thứ tự.
Tôi có nên vẫn sử dụng Locust cho bất cứ điều gì không?
Có, khi thế mạnh của nó phù hợp với nhu cầu của bạn: hành vi người dùng được định nghĩa bằng mã với các tác vụ phân nhánh và có trọng số, các client giao thức tùy chỉnh và tạo tải phân tán vượt xa 100 người dùng ảo. Hãy sử dụng đúng công cụ cho hình thức của bài kiểm thử.