Load Test trong phát triển di động — định nghĩa, kịch bản và cách thực hiện

Load Test là gì?

Load Test là quá trình xác minh cách hệ thống hoạt động dưới số lượng yêu cầu hoặc người dùng đồng thời dự kiến. Trong bối cảnh phát triển di động, Load Test được áp dụng cho cả phía máy chủ (API, cơ sở dữ liệu, bộ nhớ đệm) và phía client (xử lý thông báo push, đồng bộ dữ liệu). Sự khác biệt chính so với kiểm thử ứng suất là Load Test mô phỏng tải thực tế, không phải tải cực đoan. Theo AWS Well-Architected Framework (2024), kiểm thử tải nên được thực hiện bằng cách sử dụng hồ sơ tải dựa trên phân tích sử dụng thực tế.

Load Test có thể được thực hiện ở cấp độ yêu cầu HTTP tới API, kết nối WebSocket hoặc giao dịch cơ sở dữ liệu. Mục tiêu là đảm bảo thời gian phản hồi của mỗi yêu cầu không vượt quá ngưỡng chị định (thường là 500–1000 ms cho API) và thông lượng (RPS — yêu cầu trên giây) đáp ứng yêu cầu. Google Cloud Armor (2024) xác định giá trị ngưỡng dựa trên phân vị: thời gian phản hồi p95 không được vượt quá 2 giây cho các điểm cuối quan trọng.

Kiểm thử tải của backend di động bao gồm mô phỏng các kịch bản điển hình: đăng ký, xác thực, tải feed, gửi biểu mẫu. Các kịch bản được ghi lại dưới dạng tệp HAR (HTTP Archive) và được phát lại bởi công cụ kiểm thử tải. Theo tài liệu k6 (2025), chuyển đổi HAR có thể giảm thời gian chuẩn bị Load Test xuống 60%.

Mục tiêu của kiểm thử tải

Mục tiêu đầu tiên của Load Test là xác nhận thông lượng hệ thống. Nếu thông số kỹ thuật yêu cầu xử lý 1000 RPS, kiểm thử tải phải xác nhận điều này với biên dự phòng 20%. Theo Netflix Tech Blog (2024), kiểm thử tải tại Netflix được thực hiện với biên dự phòng gấp 2 lần tải cao điểm: nếu dự kiến 10000 RPS, kiểm tra sẽ xác nhận 20000 RPS. Cách tiếp cận này đảm bảo sự ổn định khi lưu lượng truy cập tăng đột biến.

Mục tiêu thứ hai là xác định các điểm nghẽn cổ chai (bottlenecks) trong kiến trúc. Các điểm nghẽn điển hình trong backend di động là cơ sở dữ liệu (truy vấn chậm), bộ nhớ đệm (chiến lược vô hiệu hóa không đúng) và API bên ngoài (dịch vụ bên thứ ba chậm). Theo dõi phân tán (Jaeger, Zipkin) giúp xác định vị trí vấn đề ở cấp độ một dịch vụ hoặc yêu cầu cụ thể.

Mục tiêu thứ ba là xác định điểm bão hòa (saturation point). Đây là thời điểm mà việc thêm người dùng mới không còn làm tăng thông lượng. Trong các ứng dụng di động, điểm bão hòa thường xảy ra ở mức tải CPU 70–80% trên các máy chủ cơ sở dữ liệu. Tự động mở rộng (Auto-scaling) phải kích hoạt trước khi đạt đến điểm này.

Kịch bản kiểm thử tải

Kiểm thử đột biến (Spike Test) — mô phỏng sự gia tăng đột ngột về hoạt động, chẳng hạn như chiến dịch thông báo push buổi sáng hoặc khởi động chiến dịch quảng cáo. Theo Grafana k6 (2025), Spike Test mô phỏng tăng tải từ 100 lên 10000 RPS trong 30 giây. Hệ thống phải xử lý điều này mà không mất yêu cầu và không vượt quá thời gian phản hồi hơn 50%.

Kiểm thử độ bền (Endurance Test) — kiểm tra tính ổn định của hệ thống trong quá trình vận hành kéo dài dưới tải. Thời gian điển hình là 1–4 giờ. Endurance Test phát hiện rò rỉ bộ nhớ trong các ứng dụng máy chủ, sự cố pool kết nối cơ sở dữ liệu và suy giảm hiệu suất bộ nhớ đệm. Pool kết nối PostgreSQL dưới tải kéo dài mà không có cấu hình phù hợp có thể cạn kiệt các kết nối khả dụng trong vòng 2–3 giờ hoạt động.

Kiểm thử tải tăng dần (Step Load Test) — tăng tải dần dần với bước 10–20% sau mỗi 2–5 phút. Kịch bản này giúp tìm ra ranh giới chính xác sau đó hệ thống suy giảm. InfluxDB và Prometheus thu thập các chỉ số ở mỗi bước để xây dựng biểu đồ thời gian phản hồi so với RPS.

Chỉ số Load Test

Thời gian phản hồi

Thời gian phản hồi (Response Time) là chỉ số chính của Load Test. Được đo bằng mili giây và phân tích theo phân vị: p50 (trung vị), p95 và p99. Google SRE (2024) khuyến nghị ngưỡng p95 không quá 1000 ms cho REST API và không quá 200 ms cho gRPC. Phân vị quan trọng hơn giá trị trung bình vì chúng cho thấy hành vi của những yêu cầu tệ nhất mà người dùng nhận thấy đầu tiên. Apdex (Chỉ số hiệu suất ứng dụng) là một chỉ số tổng hợp xem xét tỷ lệ người dùng hài lòng, có thể chấp nhận và thất vọng.

Thông lượng

Thông lượng (Throughput) — số lượng yêu cầu thành công trên mỗi đơn vị thời gian. Được đo bằng RPS (yêu cầu trên giây) hoặc TPS (giao dịch trên giây). Biểu đồ Throughput trong tọa độ “thời gian — RPS” phải tuyến tính cho đến điểm bão hòa. Sự sụt giảm đột ngột của Throughput khi tăng tải là dấu hiệu đạt đến giới hạn hệ thống. Apache Bench và wrk là các công cụ CLI đơn giản để kiểm tra nhanh Throughput trong quá trình phát triển.

Tỷ lệ lỗi

Tỷ lệ lỗi (Error Rate) — tỷ lệ phản hồi có trạng thái HTTP 4xx hoặc 5xx so với tổng số yêu cầu. Ngưỡng chấp nhận được là dưới 1%. Các lỗi 429 (Too Many Requests) và 503 (Service Unavailable) dưới tải cao cho thấy sự cần thiết phải cấu hình giới hạn tốc độ và tự động mở rộng. Bộ giới hạn tốc độ ở phía API Gateway bảo vệ backend khỏi vượt quá tải cho phép. Chính sách thử lại với backoff theo cấp số nhân giúp client xử lý chính xác các lỗi tạm thời.

Công cụ cho Load Test

k6 (Grafana)

k6 — công cụ kiểm thử tải mã nguồn mở hàng đầu của Grafana. Các tập lệnh được viết bằng JavaScript, hỗ trợ các kịch bản mô-đun, ngưỡng (thresholds) và tích hợp với Prometheus và InfluxDB. k6 có thể chạy trong CLI và trên đám mây Grafana Cloud k6. Grafana Cloud tự động xây dựng bảng điều khiển từ kết quả Load Test và so sánh chúng với dữ liệu lịch sử. k6 hỗ trợ Protocol Buffers và gRPC thông qua mô-đun k6/net/grpc riêng biệt.

Apache JMeter

Apache JMeter — công cụ Load Test kinh điển với giao diện đồ họa. Hỗ trợ nhiều giao thức: HTTP, JDBC, JMS, FTP và TCP. JMeter phù hợp hơn cho các kịch bản phức tạp với nhiều loại yêu cầu khác nhau nhưng yêu cầu cấu hình thủ công nhiều hơn so với k6. Các plugin JMeter mở rộng chức năng cho kiểm thử WebSocket và gRPC. Để thực thi phân tán, JMeter sử dụng kiến trúc master-slave với một bộ điều khiển.

Locust

Locust — công cụ dựa trên Python cho phép mô tả các kịch bản tải trong mã. Locust thuận tiện cho các nhóm sử dụng Python làm ngôn ngữ tự động hóa chính. Không giống k6 và JMeter, Locust hỗ trợ thực thi phân tán tích hợp sẵn: một nút master điều phối nhiều nút worker. Thực thi phân tán cho phép tạo tải lên đến 100000 RPS từ nhiều máy. Locust cũng hỗ trợ kiểm thử WebSocket thông qua các tiện ích mở rộng tùy chỉnh.

import http from 'k6/http'
import check from 'k6'
import sleep from 'k6'

export const options = {
    stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 200 },
    ],
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed: ['rate<0.01'],
    }
}

export default function() {
    const res = http.get('https://api.example.com/users')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
    sleep(1)
}

Ví dụ viết Load Test bằng k6

Tập lệnh k6 trên thể hiện một cấu trúc kiểm thử tải điển hình. Options xác định hồ sơ tải: ramp-up trong 2 phút đến 100 người dùng, sau đó 5 phút tải không đổi và ramp-up tiếp đến 200 người dùng. Các ngưỡng xác định tiêu chí đậu kiểm tra: thời gian yêu cầu p95 không quá 500 ms, tỷ lệ lỗi dưới 1%. Nếu vượt quá ngưỡng, k6 thoát với mã khác không — điều này cho phép tích hợp Load Test vào CI/CD.

Trong phát triển di động, Load Test phía máy chủ đặc biệt quan trọng khi ra mắt các tính năng mới tạo thêm tải: lượt thích, bình luận, phát trực tiếp. Khuyến nghị — thực hiện Load Test trên mỗi staging trước khi triển khai lên sản xuất. Tạo hồ sơ tải cơ sở trong giai đoạn thiết kế API giúp tránh các vấn đề kiến trúc ở các giai đoạn sau.