Một API có thể vượt qua mọi thử nghiệm chức năng nhưng vẫn thất bại khi đưa vào sản xuất. Nó trả về dữ liệu đúng, với mã trạng thái đúng, theo lược đồ đúng, và sau đó sụp đổ ngay khi một nghìn người dùng truy cập cùng một lúc. Thử nghiệm chức năng cho bạn biết API hoạt động đúng. Thử nghiệm hiệu suất cho bạn biết API không chỉ đúng mà còn đủ nhanh để chịu được lưu lượng truy cập thực.
Hướng dẫn này giải thích thử nghiệm hiệu suất API là gì, các loại thử nghiệm quan trọng, các chỉ số cần theo dõi và cách chạy thử nghiệm hiệu suất từng bước trong Apidog.
Thử nghiệm hiệu suất API là gì
Thử nghiệm hiệu suất API đo lường cách API hoạt động dưới tải: tốc độ phản hồi, số lượng yêu cầu có thể xử lý và điểm mà nó suy giảm hoặc hỏng. Nó không phải là về việc phản hồi có đúng hay không; đó là thử nghiệm chức năng. Nó là về việc phản hồi có đến nhanh chóng và đáng tin cậy khi hệ thống chịu áp lực hay không.
Mục tiêu là tìm ra giới hạn trước khi người dùng của bạn phát hiện ra. Mọi API đều có một giới hạn, một điểm mà thời gian phản hồi tăng lên, lỗi xuất hiện hoặc dịch vụ ngừng phản hồi. Thử nghiệm hiệu suất định vị giới hạn đó trong một môi trường được kiểm soát để bạn có thể nâng cao nó, lập kế hoạch dung lượng xung quanh nó, hoặc ít nhất là biết nó tồn tại.
API là một mục tiêu tốt cho thử nghiệm hiệu suất vì chúng mang tính xác định và nhanh chóng để gọi. Không có trình duyệt để hiển thị, không có giao diện người dùng để chờ. Bạn gửi một yêu cầu, bạn đo lường phản hồi. Điều đó làm cho các thử nghiệm hiệu suất API rẻ hơn để chạy và ổn định hơn so với các thử nghiệm tải toàn diện từ đầu đến cuối.
Các loại thử nghiệm hiệu suất
“Thử nghiệm hiệu suất” là một khái niệm rộng. Bên dưới nó là một số loại thử nghiệm riêng biệt, mỗi loại trả lời một câu hỏi khác nhau.
Thử nghiệm tải (Load testing) áp dụng lưu lượng truy cập mà bạn thực sự mong đợi, khối lượng yêu cầu bình thường và cao điểm của bạn, và xác nhận API xử lý nó trong thời gian phản hồi chấp nhận được. Đây là thử nghiệm cơ bản mà hầu hết các nhóm chạy đầu tiên.
Thử nghiệm căng thẳng (Stress testing) đẩy vượt quá lưu lượng truy cập dự kiến, tăng tải cho đến khi API suy giảm hoặc thất bại. Mục đích là để tìm điểm phá vỡ và xem nó phá vỡ như thế nào. Nó chậm lại một cách từ tốn, hay nó trả về lỗi và mất dữ liệu?
Thử nghiệm đột biến (Spike testing) áp dụng một sự tăng đột ngột, mạnh mẽ về lưu lượng truy cập, loại hình mà một đợt giảm giá chớp nhoáng hoặc một khoảnh khắc lan truyền tạo ra, và kiểm tra xem API có hấp thụ được hay sụp đổ. Một hệ thống xử lý tải ổn định vẫn có thể thất bại trong một đợt đột biến.
Thử nghiệm độ bền (Soak testing), còn gọi là thử nghiệm sức chịu đựng, duy trì một tải vừa phải trong một thời gian dài, hàng giờ hoặc hàng ngày, để phát hiện các vấn đề chậm chạp: rò rỉ bộ nhớ, cạn kiệt nhóm kết nối, các tệp nhật ký làm đầy đĩa. Những vấn đề này không bao giờ xuất hiện trong một thử nghiệm tải năm phút.
Thử nghiệm khói (Smoke testing) là kiểm tra sơ bộ nhẹ nhàng: một tải nhỏ để xác nhận API và thiết lập thử nghiệm đang hoạt động trước khi bạn cam kết chạy một thử nghiệm dài, tốn kém.
Hầu hết các nhóm cần thử nghiệm tải, căng thẳng và độ bền tối thiểu. Thử nghiệm đột biến quan trọng nếu lưu lượng truy cập của bạn theo đợt.
Các chỉ số quan trọng
Một thử nghiệm hiệu suất tạo ra các con số. Đây là những con số cần đọc.
Thời gian phản hồi (Response time) là khoảng thời gian API nhận, xử lý và trả về một yêu cầu. Hãy xem xét các phân vị, không chỉ trung bình. Trung bình có thể trông ổn trong khi phân vị 95 và 99, 5% và 1% yêu cầu chậm nhất, lại không thể chấp nhận được. Người dùng thực cảm nhận phần đuôi.
Thông lượng (Throughput) là số lượng yêu cầu mà API hoàn thành mỗi giây. Nó cho bạn biết dung lượng thực của hệ thống, độc lập với số lượng người dùng được kết nối.
Người dùng đồng thời (Concurrent users) hoặc người dùng ảo là số lượng người gọi đồng thời mà thử nghiệm mô phỏng. Dung lượng thường được biểu thị bằng mức độ đồng thời tối đa mà API duy trì trước khi thời gian phản hồi vượt quá ngân sách của bạn.
Tỷ lệ lỗi (Error rate) là tỷ lệ phần trăm yêu cầu thất bại dưới tải. Một API vẫn nhanh nhưng bắt đầu trả về lỗi 500 ở mức độ đồng thời cao vẫn bị coi là thất bại trong thử nghiệm.
Sử dụng tài nguyên (Resource utilization), CPU và bộ nhớ trên máy chủ, cho bạn biết tại sao hiệu suất suy giảm. Nếu thời gian phản hồi tăng trong khi CPU vẫn ở 100%, bạn bị giới hạn bởi tính toán; nếu CPU nhàn rỗi nhưng độ trễ tăng, nút thắt cổ chai nằm ở nơi khác, thường là cơ sở dữ liệu hoặc một cuộc gọi downstream.
Một báo cáo hiệu suất tốt liên kết những điều này lại với nhau: ở mức độ đồng thời này, thông lượng đạt đỉnh, thời gian phản hồi phân vị 95 là thế này, và tỷ lệ lỗi là thế kia.
Cách chạy thử nghiệm hiệu suất API trong Apidog
Apidog bao gồm chức năng thử nghiệm tải được tích hợp sẵn trong cùng không gian làm việc nơi bạn thiết kế và thử nghiệm chức năng API của mình, vì vậy bạn không cần một công cụ riêng biệt để bắt đầu.
Bước 1: Chọn điểm cuối hoặc kịch bản để thử nghiệm. Chọn một điểm cuối quan trọng duy nhất, hoặc một kịch bản thử nghiệm nhiều bước phản ánh một luồng người dùng thực, chẳng hạn như đăng nhập sau đó tìm nạp dữ liệu. Thử nghiệm một luồng thực tế mang lại các con số trung thực hơn so với việc tấn công một điểm cuối một cách riêng lẻ.
Bước 2: Xác nhận nó vượt qua chức năng trước tiên. Chạy yêu cầu với các xác nhận của nó một lần. Không có giá trị gì khi thử nghiệm tải một điểm cuối trả về dữ liệu sai; hãy sửa lỗi trước khi đo tốc độ.
Bước 3: Cấu hình tải. Đặt số lượng người dùng ảo và thời gian thử nghiệm. Apidog cho phép bạn tăng dần tải, mô phỏng người dùng tham gia theo thời gian thay vì tất cả cùng một lúc, điều này tạo ra một bức tranh thực tế hơn và giúp xác định mức độ đồng thời mà hiệu suất thay đổi.
Bước 4: Chạy thử nghiệm. Apidog thực hiện tải và báo cáo trực tiếp: thời gian phản hồi, thông lượng, tỷ lệ lỗi và cách mỗi chỉ số thay đổi khi mức độ đồng thời tăng lên. Hãy chú ý đến điểm uốn nơi thời gian phản hồi bắt đầu tăng nhanh hơn tải.
Bước 5: Đọc kết quả và tìm nút thắt cổ chai. Nếu thời gian phản hồi phân vị 95 vượt quá ngân sách của bạn ở 300 người dùng đồng thời, đó là giới hạn hiện tại của bạn. So sánh với CPU và bộ nhớ máy chủ để hiểu nguyên nhân. Chạy lại sau khi sửa lỗi để xác nhận giới hạn đã thay đổi.
Bước 6: Đối với nhu cầu nặng hơn, xuất sang JMeter. Khi bạn cần tạo tải phân tán vượt quá một máy duy nhất, Apidog có thể xuất kịch bản sang JMeter, để bạn giữ nguyên định nghĩa thử nghiệm trong khi mở rộng nguồn tải.
Tải xuống Apidog để chạy thử nghiệm tải đầu tiên của bạn đối với một điểm cuối mà bạn đã có.
Đọc kết quả hiệu suất thực tế
Các con số không có giải thích chỉ là tiếng ồn. Lấy một lần chạy cụ thể: bạn thử nghiệm tải GET /products với người dùng ảo tăng từ 0 lên 500 trong năm phút.
Trong 200 người dùng đầu tiên, thời gian phản hồi phân vị 95 giữ ổn định khoảng 180 ms và thông lượng tăng theo tải. Đây là vùng khỏe mạnh; API đang theo kịp. Khoảng 280 người dùng, thời gian phân vị 95 bắt đầu tăng, 240 ms, sau đó 400 ms, sau đó 900 ms, trong khi thông lượng lại ổn định thay vì tăng. Sự ổn định đó là tín hiệu: API đã đạt giới hạn của nó. Việc thêm nhiều người dùng bây giờ sẽ tạo ra phản hồi chậm hơn, chứ không phải hoàn thành nhiều công việc hơn. Sau 420 người dùng, tỷ lệ lỗi tăng lên trên 1% khi các yêu cầu bắt đầu hết thời gian chờ.
Phán quyết là cụ thể. API này thoải mái phục vụ khoảng 250 người dùng đồng thời trong ngân sách 200 ms. Giới hạn thực tế của nó gần 280, và nó bắt đầu thất bại khoảng 420. Nếu bạn mong đợi lưu lượng truy cập cao nhất là 200 người dùng đồng thời, bạn có khoảng trống. Nếu bạn mong đợi 350, bạn có một vấn đề cần khắc phục trước khi ra mắt, chứ không phải sau đó.
Đó là những gì một thử nghiệm hiệu suất mang lại: không phải “đạt” hay “thất bại,” mà là một bản đồ rõ ràng về nơi API hoạt động thoải mái, nơi nó căng thẳng và nơi nó bị hỏng.
Các nút thắt cổ chai hiệu suất API phổ biến
Khi một thử nghiệm phát hiện một giới hạn, nguyên nhân thường là một trong số ít những thủ phạm quen thuộc.
Các truy vấn cơ sở dữ liệu chậm là phổ biến nhất. Một cột không được lập chỉ mục, một mẫu truy vấn N+1, hoặc một giới hạn truy vấn bị thiếu làm cho một điểm cuối nhanh trở nên chậm ngay khi khối lượng dữ liệu hoặc mức độ đồng thời tăng lên. Nếu độ trễ tăng trong khi CPU máy chủ vẫn thấp, hãy nghi ngờ cơ sở dữ liệu trước.
Các cuộc gọi bên ngoài bị chặn kéo một điểm cuối xuống tốc độ của phần phụ thuộc chậm nhất của nó. Một API gọi nhà cung cấp thanh toán hoặc dịch vụ bên thứ ba một cách đồng bộ sẽ kế thừa độ trễ và sự cố của dịch vụ đó.
Cạn kiệt nhóm kết nối (Connection pool exhaustion) xuất hiện dưới tải duy trì: API hết các kết nối cơ sở dữ liệu hoặc máy khách HTTP và các yêu cầu xếp hàng chờ đợi. Đây là một phát hiện kinh điển của thử nghiệm độ bền.
Việc tuần tự hóa kém hiệu quả (Inefficient serialization) của các phản hồi có tải trọng lớn làm tiêu tốn CPU. Trả về nhiều dữ liệu hơn mức mà máy khách cần sẽ làm cho mọi phản hồi mất nhiều thời gian hơn để xây dựng và chậm hơn để truyền tải.
Một thử nghiệm hiệu suất chỉ ra nơi giới hạn nằm; kết hợp nó với các chỉ số phía máy chủ cho bạn biết tại sao.
Xây dựng thử nghiệm hiệu suất vào quy trình của bạn
Một lần chạy thử nghiệm hiệu suất trước một đợt ra mắt lớn rất hữu ích. Một thử nghiệm hiệu suất chạy thường xuyên có giá trị hơn nhiều, vì hiệu suất suy giảm âm thầm. Một truy vấn cơ sở dữ liệu mới, một cuộc gọi downstream được thêm vào, hoặc một cột không được lập chỉ mục đều có thể thêm độ trễ mà không có thử nghiệm chức năng nào nhận thấy.
Đặt ngân sách thời gian phản hồi và tỷ lệ lỗi cho các điểm cuối quan trọng của bạn, và coi việc vi phạm là một thất bại, giống như bạn coi một xác nhận bị hỏng. Chạy một thử nghiệm tải nhẹ hơn như một phần của CI/CD để một sự suy giảm xuất hiện ở yêu cầu kéo, và dành các lần chạy căng thẳng và độ bền nặng cho thử nghiệm trước khi phát hành theo lịch trình.
Giữ thử nghiệm hiệu suất bên cạnh thử nghiệm chức năng. Khi hai loại này cùng tồn tại, mọi thay đổi API đều được kiểm tra cả về tính đúng đắn và tốc độ, và “nó hoạt động” và “nó hoạt động đủ nhanh” không còn là những câu hỏi riêng biệt, dễ bị lãng quên.
Các câu hỏi thường gặp
Sự khác biệt giữa thử nghiệm tải và thử nghiệm căng thẳng là gì? Thử nghiệm tải áp dụng lưu lượng truy cập mà bạn mong đợi và xác nhận API xử lý được. Thử nghiệm căng thẳng đẩy vượt quá mức đó để tìm điểm phá vỡ. Thử nghiệm tải xác minh hoạt động bình thường; thử nghiệm căng thẳng lập bản đồ chế độ lỗi.
Tôi nên xem xét thời gian phản hồi trung bình hay phân vị? Phân vị. Trung bình che giấu phần đuôi chậm. Phân vị 95 và 99 cho thấy những gì người dùng kém may mắn nhất của bạn thực sự trải nghiệm, và đó là điều gây ra khiếu nại.
Tôi có thể thử nghiệm hiệu suất API trước khi phần backend hoàn thành không? Bạn có thể thử nghiệm hợp đồng và thiết kế, nhưng các con số độ trễ có ý nghĩa cần cơ sở hạ tầng thực tế. Sử dụng máy chủ giả lập cho công việc chức năng ban đầu, và chạy thử nghiệm tải đối với việc triển khai thực tế.
Các thử nghiệm hiệu suất nên chạy bao lâu một lần? Chạy một thử nghiệm tải nhẹ trong CI trên mỗi thay đổi đối với các điểm cuối quan trọng, và thử nghiệm căng thẳng và độ bền đầy đủ trước mỗi bản phát hành lớn. Hiệu suất suy giảm âm thầm, vì vậy kiểm tra thường xuyên tốt hơn là một lần chạy lớn trước khi ra mắt.