Mở đầu — vì sao bài này quan trọng
Nếu bạn hỏi mười kỹ sư "Performance testing là gì?", chín người sẽ trả lời đại loại: "Là kiểm tra xem hệ thống có chạy nhanh không." Câu trả lời đó không sai, nhưng nó nông và nguy hiểm — vì nó khiến bạn tập trung vào sai thứ, đo sai thứ, và rồi báo cáo sai thứ cho những người ra quyết định.
Sự thật là: performance testing hiếm khi tồn tại vì lý do kỹ thuật thuần túy. Nó tồn tại để trả lời những câu hỏi kinh doanh mà không ai dám trả lời bằng cảm tính. "Nếu ngày 12/12 có 50.000 người vào cùng lúc, website có sập không?" "Chúng ta cần thuê thêm bao nhiêu server để chịu được đợt quảng cáo Tết?" "Trang thanh toán chậm 2 giây thì mỗi tháng công ty mất bao nhiêu doanh thu?" Đây không phải câu hỏi của lập trình viên — đây là câu hỏi của CEO, của giám đốc vận hành, của người giữ ngân sách.
Bài học này là nền móng tư duy cho toàn bộ khóa học. Trước khi bạn học cách bấm nút trong JMeter hay viết script k6 (những bài sau sẽ dạy kỹ), bạn phải hiểu tại sao bạn làm điều đó. Một người biết công cụ nhưng không hiểu mục đích sẽ tạo ra những con số vô nghĩa. Một người hiểu mục đích, dù công cụ còn vụng, vẫn tạo ra giá trị. Bài này giúp bạn trở thành người thứ hai.
Khái niệm cốt lõi
Performance testing thực chất là gì
Performance testing là hoạt động đo lường và đánh giá cách một hệ thống phần mềm hành xử dưới tải — nghĩa là khi có nhiều người dùng, nhiều yêu cầu, hoặc nhiều dữ liệu tác động vào nó cùng lúc. Từ khóa quan trọng nhất ở đây là "dưới tải" (under load). Một chức năng có thể hoạt động hoàn hảo khi bạn ngồi test một mình, nhưng vỡ vụn khi có 5.000 người dùng đồng thời. Functional testing (kiểm thử chức năng) trả lời câu hỏi "nó có làm đúng việc không?"; performance testing trả lời câu hỏi "nó có làm đúng việc khi bị ép không, và ép đến đâu thì gục?".
Hãy phân biệt rõ ba khái niệm hay bị nhầm lẫn:
- Performance (hiệu năng): hệ thống phản hồi nhanh hay chậm, xử lý được bao nhiêu việc trong một đơn vị thời gian.
- Scalability (khả năng mở rộng): khi tăng tài nguyên (thêm server, thêm CPU), hệ thống có xử lý được nhiều hơn tương ứng không.
- Reliability/Stability (độ ổn định): hệ thống có duy trì được hiệu năng đó trong thời gian dài mà không rò rỉ bộ nhớ, không tích lũy lỗi không.
Bốn câu hỏi business mà performance testing thực sự trả lời
Đây là phần cốt lõi nhất của bài. Performance testing không phải để "đo cho vui" — nó phục vụ bốn nhóm câu hỏi kinh doanh:
1. Câu hỏi về doanh thu và trải nghiệm. Tốc độ là tiền. Amazon từng công bố một phát hiện kinh điển: mỗi 100 mili-giây chậm đi trên trang, doanh số giảm khoảng 1%. Google phát hiện trang tìm kiếm chậm thêm nửa giây làm lượng tìm kiếm giảm 20%. Với một sàn thương mại điện tử Việt Nam có doanh thu 100 tỷ/năm, một cải thiện latency giúp tăng 2% chuyển đổi có thể tương đương 2 tỷ đồng. Performance testing chính là công cụ chứng minh điều này bằng số liệu, thay vì tranh cãi cảm tính.
2. Câu hỏi về giới hạn chịu đựng (capacity). "Hệ thống của chúng ta chịu được tối đa bao nhiêu người dùng đồng thời trước khi bắt đầu trả lỗi?" Không ai muốn biết câu trả lời này vào đúng lúc khách hàng đang tràn vào. Bạn muốn biết nó trước, trong phòng thí nghiệm, khi hậu quả duy nhất là một dòng log đỏ.
3. Câu hỏi về đầu tư hạ tầng. Cloud tính tiền theo tài nguyên. Nếu bạn biết một server xử lý được 800 request/giây và dịp cao điểm cần 5.000 request/giây, bạn tính ngay ra cần khoảng 7 server. Không có performance testing, bạn hoặc mua thừa (đốt tiền) hoặc mua thiếu (sập hệ thống). Đây là lý do các công ty lớn gắn chặt performance test với việc lập kế hoạch ngân sách hạ tầng.
4. Câu hỏi về rủi ro và uy tín. Một lần sập trang vào đúng dịp sale lớn không chỉ mất doanh thu ngày hôm đó — nó lên báo, lên mạng xã hội, làm khách hàng mất niềm tin lâu dài. Performance testing là bảo hiểm rủi ro: nó biến "chúng ta hy vọng nó không sập" thành "chúng ta đã kiểm chứng nó chịu được gấp 3 lần tải dự kiến".
Performance testing KHÔNG phải là gì
Để tránh ngộ nhận, cần nói rõ ranh giới. Performance testing không phải là tối ưu code (đó là việc của developer sau khi bạn chỉ ra vấn đề). Nó không phải là monitoring production (monitoring theo dõi hệ thống thật đang chạy; performance testing chủ động tạo tải trong môi trường kiểm thử). Và nó không phải là một hoạt động làm một lần rồi xong — hiệu năng thoái hóa theo mỗi lần release, nên đây là việc lặp lại liên tục. Vai trò của bạn — người làm performance testing — là phát hiện và định lượng vấn đề, đưa bằng chứng cho đúng người, chứ không nhất thiết tự tay sửa.
Tình huống thực tế
Tình huống 1: Sàn thương mại điện tử và cú sập 12/12
Một sàn thương mại điện tử tầm trung ở Việt Nam — ta gọi là ShopViet — có lượng truy cập bình thường khoảng 3.000 người dùng đồng thời. Đội kỹ thuật tự tin vì "hệ thống chạy mượt cả năm nay". Đến 0h ngày 12/12, chiến dịch flash sale mở màn, lượng truy cập vọt lên 40.000 người trong vòng 90 giây. Trang chủ tải chậm dần rồi trắng xóa; nút "Đặt hàng" bấm không phản hồi; nhiều khách bị trừ tiền nhưng đơn không được ghi nhận.
Diễn giải: Vấn đề không nằm ở chức năng — mọi thứ hoạt động tốt ở tải bình thường. Vấn đề là hệ thống chưa bao giờ được kiểm thử ở mức tải đỉnh dự kiến. Đội ngũ đã nhầm "chạy mượt hằng ngày" với "sẵn sàng cho sự kiện". Nếu họ chạy một load test mô phỏng 50.000 người dùng trước đó một tháng, họ đã phát hiện điểm nghẽn (thường là database connection pool cạn kiệt) và có thời gian xử lý.
Bài học rút ra: Performance testing tồn tại chính xác cho những khoảnh khắc bất thường, không phải cho ngày thường. Câu hỏi business mà lẽ ra ShopViet phải trả lời trước là: "Chúng ta chịu được đỉnh tải của 12/12 không?" — và họ chỉ trả lời được bằng test, không bằng niềm tin.
Tình huống 2: Ngân hàng số và cái giá của 2 giây
Một ngân hàng số ở Đông Nam Á triển khai tính năng chuyển khoản mới. Về mặt chức năng, chuyển khoản hoạt động chính xác 100%. Nhưng ở giờ cao điểm buổi trưa (khi mọi người thanh toán tiền ăn), thời gian xác nhận giao dịch tăng từ 0,8 giây lên 4,5 giây. Không có giao dịch nào thất bại — nên đội monitoring không báo động. Tuy nhiên bộ phận chăm sóc khách hàng ghi nhận số lượng người dùng bấm nút chuyển khoản nhiều lần (vì tưởng bị treo), tạo ra các giao dịch trùng và khiếu nại.
Diễn giải: Đây là ví dụ cho thấy performance là vấn đề trải nghiệm và niềm tin, không chỉ là "sập/không sập". Hệ thống "vẫn chạy" nhưng chậm đủ để phá vỡ hành vi người dùng. Một performance test đo latency ở giờ cao điểm (không chỉ đo lỗi) đã phát hiện được điều này trước khi nó thành khủng hoảng vận hành.
Bài học rút ra: Mục đích thực sự của performance testing bao gồm cả việc bảo vệ cảm nhận của người dùng. "Không lỗi" không có nghĩa là "đủ tốt". Bạn phải đo cả những chỉ số như thời gian phản hồi, không chỉ tỷ lệ thành công.
Tình huống 3: Startup SaaS và bài toán ngân sách cloud
Một startup SaaS về quản lý nhà hàng đang chuẩn bị gọi vốn vòng Series A. Nhà đầu tư hỏi: "Nếu số khách hàng tăng 10 lần trong 12 tháng, chi phí hạ tầng của các bạn tăng bao nhiêu?" Đội kỹ thuật ban đầu chỉ đoán mò. Sau đó họ chạy một loạt load test ở các mức tải 1x, 3x, 5x, 10x và đo tài nguyên tiêu thụ tương ứng. Kết quả cho thấy đến mức 5x, một dịch vụ xử lý báo cáo bắt đầu tiêu tốn CPU theo cấp số nhân — một điểm nghẽn về scalability.
Diễn giải: Ở đây performance testing không nhằm tìm bug hay chống sập, mà để dự báo chi phí và lập kế hoạch mở rộng. Nhờ số liệu, startup vừa trả lời được câu hỏi của nhà đầu tư một cách thuyết phục, vừa biết cần refactor dịch vụ báo cáo trước khi tăng trưởng.
Bài học rút ra: Performance testing là đầu vào cho quyết định tài chính và chiến lược, không chỉ là công cụ QA. Người làm performance giỏi biết diễn giải con số kỹ thuật thành ngôn ngữ kinh doanh.
Hướng dẫn từng bước
Đây chưa phải lúc mở JMeter hay k6 (các bài sau sẽ hướng dẫn cài đặt và thao tác). Ở bài nền tảng này, "từng bước" nghĩa là cách bạn tư duy trước một yêu cầu performance testing. Hãy tập thói quen đi qua sáu bước sau cho mọi dự án:
- Xác định câu hỏi business. Đừng bắt đầu bằng công cụ, hãy bắt đầu bằng câu hỏi. Viết ra một câu rõ ràng: "Chúng ta cần biết hệ thống có chịu được X người dùng đồng thời với thời gian phản hồi dưới Y giây không." Nếu bạn không viết được câu này, bạn chưa sẵn sàng để test.
- Xác định đối tượng nghe kết quả. Kết quả sẽ báo cho ai — trưởng nhóm kỹ thuật, giám đốc vận hành, hay nhà đầu tư? Điều này quyết định bạn đo gì và trình bày thế nào. Một con số "throughput 800 req/s" vô nghĩa với CEO nhưng "chịu được gấp 3 lần tải Tết" thì rất có nghĩa.
- Định nghĩa tiêu chí thành công (mục tiêu hiệu năng). Không có mục tiêu thì test vô nghĩa. Ví dụ: "95% yêu cầu phản hồi dưới 1,5 giây khi có 10.000 người dùng đồng thời, tỷ lệ lỗi dưới 0,1%." Đây chính là hạt giống của khái niệm SLA/SLO mà khóa học sẽ đào sâu ở các bài sau.
- Ước lượng tải thực tế. Nhìn vào dữ liệu thật: số người dùng hằng ngày, đỉnh tải lịch sử, dự báo tăng trưởng, các sự kiện đặc biệt (sale, Tết). Tải bạn dựng phải phản ánh thực tế, không phải con số bốc đại.
- Chọn loại test phù hợp với câu hỏi. Câu hỏi khác nhau cần loại test khác nhau — load, stress, spike, soak (bài kế tiếp trong khóa học sẽ phân biệt kỹ). Ví dụ, câu hỏi "chịu được đỉnh 12/12 không" cần spike test, còn "chạy liên tục 8 tiếng có rò rỉ bộ nhớ không" cần soak test.
- Lên kế hoạch diễn giải và báo cáo ngay từ đầu. Trước khi chạy, hãy tưởng tượng slide kết quả trông thế nào. Điều này buộc bạn xác định trước các chỉ số cần thu thập, tránh chạy xong mới nhận ra thiếu dữ liệu.
Lỗi thường gặp & mẹo
Lỗi 1 — Test mà không có mục tiêu. Nhiều người mở JMeter, dựng 1.000 user, bấm chạy, rồi nhìn đồ thị mà không biết "bao nhiêu là đủ tốt". Không có ngưỡng, mọi con số đều vô nghĩa. Mẹo: luôn viết tiêu chí thành công trước khi chạy.
Lỗi 2 — Nhầm functional testing với performance testing. "Tôi test rồi, nó chạy đúng mà" — nhưng bạn chỉ test một mình. Mẹo: luôn tự hỏi "đúng khi bao nhiêu người dùng cùng lúc?".
Lỗi 3 — Chỉ nhìn giá trị trung bình. Latency trung bình 1 giây nghe ổn, nhưng có thể 5% người dùng phải chờ 10 giây. Mẹo: luôn nhìn các mốc phân vị (percentile) như p95, p99 — chúng phản ánh trải nghiệm của nhóm người dùng tệ nhất, thường là nhóm quan trọng.
Lỗi 4 — Test trên môi trường không giống production. Chạy test trên laptop rồi kết luận cho hệ thống thật là sai lầm phổ biến. Mẹo: cố gắng đưa môi trường test càng gần production càng tốt, và luôn ghi rõ sự khác biệt khi báo cáo.
Lỗi 5 — Đo sai thứ và báo cáo cho sai người. Đưa một trưởng phòng kinh doanh xem đồ thị GC log là cách nhanh nhất để họ ngừng quan tâm. Mẹo: dịch con số kỹ thuật thành tác động kinh doanh — doanh thu, chi phí, rủi ro.
Mẹo tư duy tổng quát: Hãy luôn bắt đầu bằng câu hỏi "Ai cần biết điều gì, và họ sẽ ra quyết định gì dựa trên kết quả này?". Performance testing giỏi không phải là chạy được nhiều user nhất, mà là trả lời đúng câu hỏi quan trọng nhất.
Bài tập thực hành
Bài tập này không cần cài phần mềm — mục tiêu là rèn tư duy nền tảng.
- Chọn một hệ thống bạn biết (một ứng dụng, một website — có thể là nơi bạn đang làm, hoặc một sàn thương mại điện tử quen thuộc). Viết ra ba câu hỏi business mà performance testing có thể trả lời cho hệ thống đó. Mỗi câu phải cụ thể, có con số (ví dụ: "Chịu được 20.000 người xem livestream bán hàng đồng thời không?").
- Với mỗi câu hỏi, xác định: (a) ai là người cần biết câu trả lời, (b) họ sẽ ra quyết định gì, (c) tiêu chí thành công cụ thể là gì (ngưỡng latency, tỷ lệ lỗi, số user đồng thời).
- Phân biệt bằng ví dụ của riêng bạn: viết một tình huống mà hệ thống "đúng chức năng nhưng tệ hiệu năng". Mô tả cách nó ảnh hưởng đến người dùng thật và đến doanh thu.
- Dịch số sang tiền: giả định trang thanh toán của hệ thống bạn chọn chậm thêm 1 giây làm tỷ lệ chuyển đổi giảm 3%. Nếu doanh thu tháng là 5 tỷ đồng, ước lượng số tiền mất mỗi tháng. (Gợi ý: đây chính là loại lập luận bạn sẽ dùng để thuyết phục lãnh đạo đầu tư vào performance.)
Tóm tắt
Performance testing không phải là "đo xem hệ thống có nhanh không" — đó là cách nhìn hời hợt. Bản chất của nó là dùng bằng chứng định lượng để trả lời các câu hỏi kinh doanh về doanh thu, giới hạn chịu tải, đầu tư hạ tầng và rủi ro. Nó khác với functional testing ở chỗ luôn đặt hệ thống "dưới tải", và khác với monitoring ở chỗ chủ động tạo tải trong môi trường kiểm thử.
Ba tình huống thực tế — cú sập 12/12 của sàn thương mại điện tử, cái giá 2 giây của ngân hàng số, và bài toán ngân sách cloud của startup — cho thấy performance testing phục vụ những quyết định vượt xa phạm vi kỹ thuật. Người làm performance giỏi luôn bắt đầu bằng câu hỏi "Ai cần biết điều gì?", định nghĩa tiêu chí thành công trước khi chạy, và biết dịch con số kỹ thuật thành ngôn ngữ kinh doanh.
Với nền tảng tư duy này, bạn đã sẵn sàng bước sang bài tiếp theo — nơi chúng ta phân loại các dạng test (load, stress, spike, soak) để mỗi câu hỏi business tìm được đúng công cụ trả lời.