Ứng dụng của bạn hoạt động hoàn hảo với mười người dùng. Điều gì xảy ra vào ngày bán hàng với mười nghìn? Thử nghiệm tải và kiểm tra căng thẳng mô tả hai cách khác nhau để trả lời câu hỏi đó và việc trộn lẫn chúng sẽ dẫn đến các thử nghiệm không chứng minh được những gì bạn nghĩ.

Hướng dẫn này giải thích nội dung của từng loại, các loại xét nghiệm liên quan và cách đọc kết quả. Chúng tôi đã chạy phép tính phần trăm nhỏ bên dưới trên Python 3.13, với các số được mô phỏng. Các tập lệnh k6 là các ví dụ minh họa mà chúng tôi không thực thi và số lượng người dùng cũng như mục tiêu được phát minh ra, vì vậy hãy thay thế chúng bằng tập lệnh của riêng bạn. Chỉ chạy các thử nghiệm này đối với các hệ thống mà bạn sở hữu hoặc có quyền kiểm tra, vì lưu lượng truy cập lớn có thể giống như một cuộc tấn công và gây ra tình trạng ngừng hoạt động thực sự.

Câu trả lời ngắn gọn

Thử nghiệm tải hỏi: liệu chúng tôi có thể xử lý lưu lượng truy cập mà chúng tôi mong đợi và đạt được mục tiêu khi thực hiện việc đó không? Bài kiểm tra căng thẳng hỏi: chúng ta có thể mất bao nhiêu trước khi thất bại, chúng ta thất bại như thế nào và chúng ta phục hồi nhanh như thế nào?

Hãy nghĩ về một cây cầu. Kiểm tra tải trọng cho số lượng xe tải dự kiến ​​đi qua và xác nhận rằng nó ổn. Bài kiểm tra căng thẳng tiếp tục tăng thêm sức nặng để tìm hiểu giới hạn của nó và liệu nó có đưa ra cảnh báo trước hay không. May mắn thay, việc phá vỡ phần mềm lại rẻ hơn so với việc phá một cây cầu.

Kiểm tra tải và kiểm tra căng thẳng cạnh nhau

Kiểm tra tải là gì?

Kiểm tra tải mô phỏng lưu lượng truy cập thực tế mà bạn mong đợi và đo lường cách hệ thống hoạt động. Nó cần một mục tiêu để kiểm tra, ví dụ: “với 500 người dùng đồng thời, 95% yêu cầu thanh toán kết thúc trong vòng 800 mili giây, với dưới 1% lỗi”.

Đây là cách nó có thể trông giống như một tập lệnh k6. Các bài kiểm tra k6 được viết bằng JavaScript và thresholds biến mục tiêu của bạn thành kết quả đạt hoặc không đạt:

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  stages: [
    { duration: "5m", target: 500 },   // ramp up
    { duration: "20m", target: 500 },  // hold at expected peak
    { duration: "2m", target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ["p(95)<800"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/products");
  sleep(1);   // think time, as real users pause
}

sleep quan trọng. Không cần thời gian suy nghĩ, mỗi người dùng ảo sẽ truy cập máy chủ liên tục, tạo ra lưu lượng truy cập nhiều hơn so với cùng số lượng người thật.

Kiểm tra căng thẳng là gì?

Kiểm tra căng thẳng có chủ ý vượt quá mức mong đợi. Bạn không cố gắng vượt qua. Bạn muốn có câu trả lời cho những câu hỏi như:

• Hiệu suất bắt đầu suy giảm ở mức độ nào?
• Thành phần nào bị lỗi đầu tiên: cơ sở dữ liệu, máy chủ ứng dụng hoặc lệnh gọi của bên thứ ba?
• Nó có bị lỗi với các lỗi rõ ràng hay bị treo và mất dữ liệu?
• Nó có tự phục hồi khi lưu lượng truy cập giảm không?

export const options = {
  stages: [
    { duration: "5m", target: 500 },    // expected peak
    { duration: "5m", target: 1000 },   // beyond it
    { duration: "5m", target: 2000 },   // further
    { duration: "5m", target: 4000 },   // likely to break
    { duration: "10m", target: 0 },     // recovery: does it come back?
  ],
};

Giai đoạn phục hồi cuối cùng đó thường bị lãng quên và có thể là giai đoạn có giá trị nhất. Một hệ thống xử lý lỗi tốt nhưng không bao giờ phục hồi nếu không khởi động lại thủ công vẫn đồng nghĩa với việc mất điện để ai đó khắc phục vào lúc nửa đêm. Lý tưởng nhất là dưới mức tải cực lớn, hệ thống sẽ loại bỏ công việc một cách có kiểm soát, trả về 503 phản hồi rõ ràng thay vì hết thời gian chờ.

Spike, ngâm và các loại khác

Kiểm tra tải và căng thẳng thuộc nhóm kiểm tra hiệu suất rộng hơn:

Các bài kiểm tra Ngâm nắm bắt được các vấn đề mà các bài kiểm tra ngắn không bao giờ nhìn thấy. Một rò rỉ bộ nhớ nhỏ có thể trông vô hại trong 20 phút và chỉ khiến dịch vụ ngừng hoạt động sau hai ngày. Thử nghiệm tăng đột biến phù hợp với các sự kiện như bán hàng chớp nhoáng, nơi lưu lượng truy cập không tăng dần.

Số liệu quan trọng

Tại sao mức trung bình đánh lừa

Mức trung bình che giấu những yêu cầu chậm mà người thật phàn nàn. Để hiển thị điều này, chúng tôi đã tạo 100 thời gian phản hồi mô phỏng, trong đó 95 thời gian phản hồi nhanh (80 đến 200 mili giây) và 5 thời gian phản hồi rất chậm (2,5 đến 4 giây), sau đó tính toán số liệu thống kê chung:

import math, random, statistics

random.seed(3)
times = [random.randint(80, 200) for _ in range(95)] \
      + [random.randint(2500, 4000) for _ in range(5)]

def pct(values, p):
    values = sorted(values)
    return values[math.ceil(p / 100 * len(values)) - 1]

print("avg", round(statistics.mean(times)), "p50", pct(times, 50),
      "p95", pct(times, 95), "p99", pct(times, 99), "max", max(times))

# avg 302 p50 150 p95 199 p99 3740 max 3896

Hãy nhìn kỹ vào những con số đó. Trung bình 302 ms không mô tả được ai. Các yêu cầu thông thường mất khoảng 150 mili giây, trong khi các yêu cầu chậm mất hơn 3 giây. Ngay cả p95 trông vẫn ổn ở tốc độ 199 ms và chỉ p99 mới bộc lộ vấn đề. Một con số như p95 có nghĩa là 95% yêu cầu nhanh hoặc nhanh hơn.

Và một phần trăm yêu cầu không phải là một sự kiện hiếm gặp. Nếu một trang thực hiện 50 yêu cầu, tốc độ p99 chậm sẽ ảnh hưởng đến phần lớn lượt xem trang. Đặt mục tiêu theo phần trăm quan trọng đối với bạn và xem xét nhiều mục tiêu cùng nhau.

Công cụ

Bất kỳ trong số này có thể chạy cả kiểm tra tải và căng thẳng. Chọn một thứ phù hợp với kỹ năng của nhóm bạn thay vì chạy theo danh sách tính năng. Để sử dụng một trong quy trình của bạn, hãy xem CI/CD là gì.

Cách lập kế hoạch kiểm tra

1. Đặt mục tiêu. Sử dụng số liệu phân tích thực tế để tìm lưu lượng truy cập cao nhất của bạn và xác định mục tiêu.
2. Chọn hành trình. Lập mô hình hành vi thực tế của người dùng, chẳng hạn như duyệt qua, tìm kiếm và thanh toán, theo tỷ lệ thực tế. Chỉ nhấn vào trang chủ chứng tỏ ít.
3. Sử dụng môi trường thực tế. Một máy chủ chạy thử nhỏ không thể dự đoán quá trình sản xuất. Lưu ý bất kỳ sự khác biệt.
4. Chuẩn bị dữ liệu. Sử dụng khối lượng thực tế vì một truy vấn nhanh trên 100 hàng có thể thu thập dữ liệu trên 10 triệu.
5. Cảnh báo mọi người. Hãy thông báo cho nhóm vận hành của bạn và bất kỳ bên thứ ba nào và đừng vô tình kiểm tra nhà cung cấp dịch vụ thanh toán. Mô phỏng các dịch vụ bên ngoài khi thích hợp.
6. Bắt đầu từ quy mô nhỏ. Trước tiên hãy chạy thử nghiệm khói nhỏ để xác nhận rằng tập lệnh của bạn hoạt động.
7. Giám sát mọi thứ. Nếu không có số liệu máy chủ, bạn sẽ thấy rằng tốc độ chậm lại chứ không phải tại sao.
8. Lặp lại. Chạy lại sau mỗi lần sửa và giữ đường cơ sở để so sánh.

Đọc kết quả

Cơ sở dữ liệu là một nút thắt cổ chai phổ biến, vì vậy nếu truy vấn là vấn đề, hãy đọc hướng dẫn của chúng tôi về Tối ưu hóa truy vấn SQL. Hàng cuối cùng của bảng là một cái bẫy quan trọng: luôn kiểm tra tình trạng của máy tạo ra tải.

Những lỗi thường gặp

• Gây nhầm lẫn cho người dùng với các yêu cầu. Hãy làm rõ liệu mục tiêu có nghĩa là người dùng đồng thời hay yêu cầu mỗi giây.
• Bỏ qua thời gian suy nghĩ. Điều này làm tăng lưu lượng truy cập và đưa ra kết quả sai lệch.
• Thử nghiệm quá muộn. Một tuần trước khi ra mắt sẽ không có thời gian để khắc phục các vấn đề về kiến ​​trúc.
• Sử dụng một điểm cuối duy nhất. Lưu lượng truy cập thực kết hợp giữa đọc, ghi và tìm kiếm.
• Bộ nhớ đệm ẩn mọi thứ. Các yêu cầu lặp lại giống hệt nhau chỉ có thể kiểm tra bộ nhớ đệm của bạn, vì vậy hãy thay đổi dữ liệu.
• Thử nghiệm một lần. Hiệu suất thay đổi theo mỗi lần phát hành, vì vậy hãy chạy thử nghiệm thường xuyên.

Lời kết

Chạy thử nghiệm tải để xác nhận rằng bạn có thể xử lý lưu lượng truy cập mà bạn mong đợi và chạy thử nghiệm căng thẳng để tìm hiểu điều gì sẽ xảy ra khi bạn không thể. Bắt đầu từ việc nhỏ: chọn hành trình người dùng quan trọng nhất của bạn, đặt một mục tiêu rõ ràng và chạy thử nghiệm ngắn theo giai đoạn có bật tính năng giám sát. Lần chạy đầu tiên đó thường dạy cho bạn điều gì đó và bạn có thể xây dựng từ đó.

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

Tiếp tục học hỏi