Ở bài viết trước K6 Performance Testing - Nhập môn, chúng ta đã tìm hiểu cơ bản về K6, bao gồm cách cài đặt trên các nền tảng, thực hiện viết, chạy kịch bản kiểm thử đơn giản và các thành phần cơ bản cấu tạo nên kịch bản kiểm thử trong K6.

Tuy nhiên, khi áp dụng vào thực tế, ở những trường hợp sẽ có những tiêu chí đánh giá khác biệt phản ánh hiệu suất ở những góc độ khác nhau, do đó chúng ta cần xác định phương pháp kiểm thử phù hợp để đo lường được kết quả như mong muốn. Trong bài viết này, chúng ta sẽ cùng khám phá các loại kiểm thử hiệu năng phổ biến và cách áp dụng chúng trong K6.

Bảng thuật ngữ

Thuật ngữGiải thích
scriptKịch bản kiểm thử
bottlenecksĐiểm gây nghẽn về hiệu năng của hệ thống
trafficLượng tải truy cập ứng dụng, dịch vụ
cachingKỹ thuật tăng tốc tải xuống những dữ liệu truy cập thường xuyên
auto-scaleKỹ thuật tự động co giãn khả năng tính toán, lưu trữ cho máy chủ

1. Test Parameters – Các tham số cấu hình

Khi viết kịch bản kiểm thử, ngoài thông tin thường được nhắc tới là khối lượng tải, bạn cần cân nhắc nhiều yếu tố khác, chúng được gọi là Test Parameters. Đây là những thông số ảnh hưởng đến cách tải trọng được phân bổ và mô phỏng:

  • Virtual Users (VUs): Mỗi VU đại diện cho một luồng hoạt động độc lập (independent thread of execution), chạy đồng thời với các VU khác.
  • Iterations: Tổng số lần lặp lại của script được thực hiện bởi VU.
  • Throughput: Lượng công việc có thể xử lý trong một khoảng thời gian nhất định, thường tính bằng VUs/second, requests/second hoặc iterations/second.
  • User flows: Trình tự các hành động mà script thực hiện, mô phỏng luồng thao tác của một người dùng thật.
  • Load profile: Cách thức đổ tải vào hệ thống, bao gồm think time (thời gian trễ giữa các iterations), tốc độ tăng/giảm VU, và thời gian chạy của từng stage trong bài test.
  • Duration: Tổng thời gian thực hiện bài test.

Dựa vào việc điều chỉnh Test Parameters, chúng ta có thể tạo ra nhiều loại kiểm thử hiệu năng khác nhau để phù hợp với từng mục tiêu kiểm thử.

2. Phân loại kiểm thử hiệu năng phổ biến & Cách thiết lập trong K6

2.1. Shakeout Test/ Smoke Test – Kiểm tra nhanh trước khi chạy test lớn

Đây là một bài kiểm thử nhỏ nhằm kiểm tra trước các vấn đề có thể ảnh hưởng đến kết quả ở những bài kiểm thử chuyên sâu sau này. Loại thử nghiệm này bao gồm các bài kiểm tra chạy với một vài VUs, thông thường nhỏ hơn 5 VUs. Cùng với như số lượng VUs nhỏ, bài kiểm tra sẽ thực thi trong một khoảng thời gian ngắn, một số lần lặp thấp hoặc thời lượng từ vài chục giây đến tối đa vài phút chỉ để kiểm tra sơ bộ kịch bản & hệ thống.

Mục đích:

✅ Phát hiện lỗi script gây sai lệch kết quả.

✅ Kiểm tra cấu hình môi trường có đúng hay không.

✅ Xác định các điểm nghẽn (bottlenecks) dù tải thấp.

image.png
image.png

Bộ tham số điển hình:

Total VUs: 5	
Ramp-up: 0 seconds	
Duration: 10 minutes
Ramp-Down: 0 seconds

Ví dụ trong K6:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  vus: 3, // Lưu ý, giữ số lượng VUs ở mức thấp ~ 2, 3, tối đa 5 VUs
  duration: '1m', // Thời gian có thể ngắn hơn hoặc chỉ vài phút
};

export default () => {
  const urlRes = http.get('https://quickpizza.grafana.com');
  sleep(1);
};

2.2. Average Load Test – Kiểm tra tải trung bình

Bài test mô phỏng mức tải trung bình trong một ngày hoạt động bình thường của hệ thống.

Cụ thể, bài kiểm thử sẽ thực hiện ramp-up dần dần sao cho để đạt được mục tiêu đủ số lượng VUs theo như kế hoạch, số lượng VUs đạt ngưỡng và sẽ giữ nguyên trong hầu hết thời lượng bài test. Ở giai đoạn cuối của bài kiểm thử, quá trình ramp-down được thự hiện để giảm bớt số VUs.

Mục đích:

✅ Xác định khả năng xử lý của hệ thống với traffic trung bình.

✅ Thiết lập performance baseline (mức hiệu suất tiêu chuẩn), có thể sử dụng cho thiết lập SLA/SLO.

Bộ tham số điển hình:

**Name: Average Load Test
Total VUs: 100	
Ramp-up: 30 minutes
Steady state: 60 minutes
Ramp-down: 10 minutes
Total duration: 100 minutes**

Ví dụ trong K6:

export let options = {
  stages: [
    { duration: '30m', target: 100 }, // Ramp-up to 100 users in 30 minutes
    { duration: '60m', target: 100 }, // Steady state for 60 minutes
    { duration: '10m', target: 0 }, // Ramp-down in 10 minutes
  ],
};

export default function () {
  let res = http.get('https://jsonplaceholder.typicode.com/comments');
}

2.3. Stress Test – Kiểm tra tải vượt giới hạn

Bài kiểm thử mô phỏng tình huống hệ thống phải xử lý lượng traffic cực lớn vào giờ cao điểm hoặc sự kiện đặc biệt. Một vài ví dụ mà bạn có thể tìm thấy bản thân mình đã đóng góp vào lượng traffic đột biến: săn sales trên Shopee, đăng ký tín chỉ học phần, xem đội tuyển bóng đá Việt Nam ở chung kết Sea Games trên ứng dụng tivi(TV360, VTV Go, FPT Play,…),…

Trong khi Avarage Load Test giả lập vào 1 ngày bình thường và tổng hợp trong 1 tuần, 1 tháng thì Stress Test sẽ tập trung vào số lượng traffic lớn nhất mà hệ thống sẽ xử lý.

Mục đích:

✅ Xác định ngưỡng crash hoặc lỗi của hệ thống, cung cấp thông tin cho việc thiết lập giới hạn bảo vệ hệ thống.

✅ Đánh giá khả năng kháng chịu khi tải vượt mức giới hạn.

✅ Góp phần xác định lượng tài nguyên của hạ tầng (CPU, RAM, DISK IO,…) cần thiết lập để đảm bảo tình huống xảy ra

Bộ tham số điển hình:

Name: Stress Test
Total VUs: 300
Ramp-up: 5 minutes
Steady state: 50 minutes
Ramp-down: 5 minutes
Total duration: 60 minutes

Ví dụ trong K6:

export let options = {
  stages: [
    { duration: '5m', target: 300 }, // Ramp-up tới 300 VUs trong vòng 5 phút đầu
    { duration: '50m', target: 300 }, // Duy trì 300 VUs trong 50 phút tiếp theo
    { duration: '5m', target: 0 }, // Ramp-down trong 5 phút cuối
  ],
};

export default function () {
  let res = http.post('https://jsonplaceholder.typicode.com/posts', {
    title: 'foo',
    body: 'bar',
    userId: 1
  });
}

2.4. Soak Test – Kiểm tra hiệu suất dài hạn

Bạn đã từng gặp ứng dụng, dịch vụ phát triển bởi Java, sau một thời gian hoạt động gặp tình trạng hết memory, hiệu năng ứng dụng sụt giảm không rõ nguyên nhân,… Và còn nhiều vấn đề khác có thể xuất hiện khi ứng dụng chạy trong thời gian dài liên tục như rò rỉ bộ nhớ, cạn kiệt tài nguyên, mất kết nối cơ sở dữ liệu,… Soak Test giúp phát hiện ra các vấn đề này thông qua thời lượng kiểm thử kéo dài. Ngoài ra, Soak Test còn được biết đến với tên gọi kiểm thử độ bền, tương tự như viễn cảnh ứng dụng của bạn ngày ngày, miệt mài phục vụ người dùng cuối.

Mục đích:

✅ Xác định memory leak, connection leak, …

✅ Kiểm tra hiệu suất khi hệ thống hoạt động trong thời gian dài.

Name: Soak Test
Total VUs: 50
Ramp-up: 30 minutes
Steady state: 480 minutes
Ramp-down: 10 minutes
Total duration: 520 minutes (8 hours and 40 minutes)

2.5. Spike Test – Mô phỏng tải tăng đột biến

Cuộc kiểm thử sẽ tạo ra tình huống giả lập ứng dụng sẽ gặp phải 1 lượng traffic tăng đột ngột và phải đảm bảo lượng throughput đạt yêu cầu. Bạn sẽ thấy Spike Test giống với Stress Test? Thực sự có một điểm khác biệt nhỏ ở đây, Spike Test không yêu cầu bạn phải thực hiện kiểm thử tới khi dịch vụ bị crash vì mục đích chính của hai phân loại kiểm thử là khác nhau.

Một số ứng dụng có thể gặp phải tình huống traffic tăng đột biến trong thời gian ngắn, ví dụ:

🎯 Săn vé sự kiện

🎯 Flash sale

🎯 Livestream hot

Mục đích:

✅ Kiểm tra khả năng phục hồi khi hệ thống gặp tải lớn bất ngờ.

✅ Đánh giá caching và auto-scaling.

Name: Spike Test	
Total VUs: 300
Ramp-up: 1 minute
Steady state: 20 minutes
Ramp-down: 5 minutes
Total duration: 26 minutes

2.6. Breakpoint Test – Kiểm tra giới hạn tải có kiểm soát

Đây là một dạng Stress Test nhưng có kiểm soát, nhằm xác định mức tải tối đa trước khi hệ thống bắt đầu chậm lại. Điều mà bạn cần tới Breakpoint Test thực sự là ngưỡng mà hiệu năng của hệ thống suy giảm bởi traffic tăng. Đưa ra được ngưỡng thông số này phần nào chứng minh rằng, bạn thực sự trân trọng người dùng của mình, mong muốn người dùng có trải nghiệm tốt ở mọi thời điểm.

Về mặt kỹ thuật, bằng cách chia nhỏ các mốc VUs chạy trong 1 chu kì, sau đó thực hiện ramp-up cho các mốc tiếp theo. Từ quá trình này chúng ta có thể xác định mức độ phản hồi của hệ thống với các mốc VUs.

Mục đích:

✅ Xác định ngưỡng tải tối đa mà hệ thống vẫn chạy ổn.

✅ Tìm ra bottleneck để tối ưu hiệu suất.

✅ Kiểm tra khả năng caching và auto-scaling.

Name: Breakpoint Test	
Total max VUs: unknown
Ramp-up: 10 minutes before each stage
Steady state: 30 minutes
Ramp-down: 0 minutes
Total duration: unknown

Tổng kết

Trong bài viết này, chúng ta đã cùng nhau tìm hiểu các loại kiểm thử hiệu năng phổ biến và cách áp dụng chúng trong K6. Tùy vào từng mục tiêu kiểm thử và đặc thù hệ thống, bạn có thể lựa chọn hình thức phù hợp. Dưới dây là bảng so sánh tổng quan:

Phân loạiVUs/ThroughputThời lượng testTrường hợp sử dụng
SmokeThấpNgắn (giây hoặc phút)Bài test giúp kiểm tra chức năng, số liệu cơ sở và độ lệch sau thay đổi script test.
Average LoadTrung bìnhTrung bình (5-60 phút)Phổ biến để kiểm tra hiệu năng trung bình trong quá trình vận hành và bảo trì hệ thống. Khi cần đưa ra thông tin hỗ trợ thiết lập ngưỡng cảnh báo trong vận hành.
StressCaoTrung bình (5-60 phút)Khi cần cân đối giữa lượng tải và lượng tài nguyên sử dụng cho hệ thống.
SoakTrung bìnhDài (đơn vị giờ)Đảm bảo chất lượng hiệu suất đồng đều trong thời gian dài.
SpikeRất caoNgắn (một vài phút)Chuẩn bị cho các đợt cao điểm (peak season) để lập kế hoạch ứng phó lượng tải tăng mà hệ thống cần đáp ứng.
BreakpointTăng tới giới hạnPhụ thuộc vào giới hạn của hệ thốngCó thể diễn ra vài lần trong năm để tìm giới hạn của hệ thống, đáp ứng yêu cầu phi chức năng.

Việc hiểu rõ từng loại kiểm thử và cách cấu hình các tham số trong K6 sẽ giúp bạn thiết kế được những bài kiểm thử sát thực tế, từ đó đánh giá chính xác hiệu suất và khả năng chịu tải của hệ thống, đồng thời phát hiện các vấn đề tiềm ẩn trước khi triển khai chính thức.

Tài liệu tham khảo: