Test tải và quy mô

Vì sao đây là việc của chặng sớm

Lỗi hiệu năng có một đặc tính khó chịu: nó không báo lỗi. Không có dòng đỏ nào, không có crash. Mọi thứ chạy đúng, chỉ chậm — và chậm dần theo lượng dữ liệu, cho tới ngày nó thành timeout.

Vì vậy nó sẽ không bao giờ bị bắt bởi test chức năng thông thường. Phải có phép đo riêng, và phép đo đó phải chạy sớm. Sửa một truy vấn thiếu chỉ mục lúc viết tốn 10 phút; phát hiện nó khi đang có 300.000 người dùng thì phải sửa dưới áp lực, giữa đêm, với dữ liệu đang nóng.

Ngân sách hiệu năng đã có ở bài riêng

Con số cụ thể cho từng luồng — cold start, warm start, API P95, crash-free, ANR — nằm ở Performance budget, cùng quy tắc đo và ngưỡng cảnh báo regression. Bài này không lặp lại, mà nói về phần còn thiếu: làm sao biết ngân sách đó còn giữ được khi có 500.000 người dùng cùng lúc.

Ngân sách hiệu năng đo một người dùng trên một thiết bị. Test tải đo cả hệ thống dưới sức nặng thật. Hai thứ khác nhau và đều bắt buộc: app mượt trên máy nhưng server sập ở giờ cao điểm thì người dùng vẫn không dùng được.

Bốn loại test tải

Loại	Câu hỏi trả lời	Khi nào chạy
Test tải	Ở tải dự kiến, hệ thống có đạt ngân sách không?	Trước mỗi release lớn
Test chịu đựng	Gãy ở mức nào, và gãy kiểu gì?	Hằng quý, và trước khi mở rộng quy mô
Test bền	Chạy 8 giờ liên tục có rò rỉ gì không?	Hằng tháng, chạy ban đêm
Test đột biến	Tải tăng vọt trong 1 phút thì sao?	Trước sự kiện, chiến dịch bán hàng

Test chịu đựng quan trọng ở phần gãy kiểu gì. Hệ thống từ chối bớt yêu cầu và giữ nguyên thời gian phản hồi là gãy đẹp. Hệ thống chậm dần đều cho tới khi mọi yêu cầu đều timeout là gãy xấu — vì lúc đó không ai làm được gì, kể cả người vào sửa.

Mục tiêu tải phải đạt

Tính từ mục tiêu 500.000 người dùng, giả định 20% hoạt động hằng ngày và tải dồn vào giờ cao điểm:

Chỉ tiêu	Mức phải chịu được
Người dùng đồng thời giờ cao điểm	50.000
Kết nối thời gian thực mở cùng lúc (Chat)	50.000
Tin nhắn mỗi giây lúc cao điểm	2.000
Yêu cầu API mỗi giây	5.000
Đơn hàng mỗi phút lúc cao điểm	500

Luật: test ở mức gấp đôi mục tiêu. Đạt đúng mức mục tiêu nghĩa là không còn chỗ thở cho tăng trưởng, cho sự kiện bất thường, hay cho một máy chủ chết giữa chừng.

Đưa phép đo vào pipeline

Chặng	Đo gì	Chặn khi
Lúc gõ code	Cảnh báo truy vấn trong vòng lặp, danh sách không phân trang	Linter báo đỏ
Mỗi PR	Kích thước gói, thời gian khởi động trên máy chuẩn	Tăng quá ngưỡng mà không có giải thích
Mỗi PR đụng tới truy vấn	Kế hoạch truy vấn trên dữ liệu cỡ lớn	Có quét toàn bảng mới
Hằng đêm trên main	Test tải rút gọn, ngân sách các luồng chính	Vượt ngưỡng chặn
Trước release	Test tải đầy đủ, test bền	Bất kỳ luồng nào vượt ngưỡng
Trên production	Số liệu thật theo nhóm 95%	Cảnh báo tự động

Dòng thứ hai là dòng có sức nặng nhất trong bảng: so sánh hiệu năng của PR với main và báo ngay trong PR. Tác giả thấy "PR này làm khởi động chậm thêm 180 ms" khi còn nhớ mình vừa viết gì — rẻ hơn rất nhiều so với việc truy ngược sau ba tuần.

Bộ dữ liệu thử cỡ lớn

Không có dữ liệu lớn thì mọi test hiệu năng đều nói dối. Bắt buộc duy trì một bộ dữ liệu giả có cỡ tương đương production:

• Người dùng: 500.000, phân bố hoạt động không đều (một số rất nhiều, phần lớn ít).
• Hội thoại: có hội thoại 100.000 tin nhắn, không chỉ hội thoại 20 tin.
• Task: có dự án 10.000 task, có task 200 bình luận.
• Đơn hàng: hai năm lịch sử, có ngày cao điểm gấp 10 lần ngày thường.

Bộ dữ liệu này sinh bằng script, không sao chép từ production. Sao chép dữ liệu thật về môi trường test là rủi ro rò rỉ dữ liệu cá nhân — xem bảo mật và quyền riêng tư.

Khi một phép đo đỏ

1. Không nới ngân sách để cho qua. Nới ngân sách là cách chính thức để app chậm dần mãi mãi.
2. Tìm nguyên nhân trong thay đổi gần nhất — hiệu năng tụt thường do đúng một thay đổi.
3. Không tìm ra trong một ngày thì rollback thay đổi đó, điều tra sau.
4. Nếu ngân sách thật sự đặt sai, đổi nó bằng một quyết định được ghi lại theo cách ra quyết định, kèm lý do và người duyệt — không phải bằng cách sửa lén con số trong tệp cấu hình.