JMeter vs k6 — Decision matrix

Mở đầu — vì sao bài này quan trọng

Đến bài này, bạn đã đi qua gần hai phần ba khóa học. Bạn biết dựng một test plan trong JMeter, biết viết script k6 bằng JavaScript, biết đặt Threshold, đọc metric, thậm chí đã thử distributed testing và đẩy kết quả lên Grafana. Nhưng khi bước vào một dự án thật — hoặc khi được sếp hỏi thẳng "team mình nên chuẩn hóa công cụ nào cho performance testing?" — thì kiến thức rời rạc về từng công cụ không đủ. Bạn cần một khung tư duy để ra quyết định, và bảo vệ được quyết định đó trước cả team dev lẫn quản lý.

Đây chính là kỹ năng phân biệt một người "biết dùng công cụ" với một Performance Engineer thực thụ. Người mới thường tranh cãi kiểu tôn giáo: "JMeter cũ rồi, k6 mới xịn hơn" hoặc "k6 không có GUI dùng bất tiện, JMeter vẫn số một". Cả hai câu này đều sai vì đều bỏ qua bối cảnh. Sự thật là không có công cụ nào "tốt hơn" một cách tuyệt đối — chỉ có công cụ phù hợp hơn với hoàn cảnh cụ thể của bạn: kỹ năng team, loại giao thức cần test, hạ tầng CI/CD, ngân sách, và cả văn hóa kỹ thuật của công ty.

Bài này sẽ trang bị cho bạn một decision matrix — ma trận ra quyết định — có tiêu chí rõ ràng, có trọng số, để bạn không chọn theo cảm tính mà chọn theo dữ kiện. Đây không phải bài "học cú pháp", mà là bài "học cách suy nghĩ như người chịu trách nhiệm về công cụ".

Khái niệm cốt lõi

Decision matrix là gì và tại sao cần trọng số

Decision matrix là một bảng liệt kê các tiêu chí đánh giá (criteria) theo hàng, các lựa chọn (options — ở đây là JMeter và k6) theo cột, rồi chấm điểm từng ô. Điểm mấu chốt khiến ma trận này hữu ích hơn một cuộc tranh luận là: mỗi tiêu chí có một trọng số (weight) phản ánh mức độ quan trọng với riêng dự án của bạn.

Ví dụ, với một team QA thuần thủ công không ai biết code, tiêu chí "độ dốc học tập" có thể chiếm trọng số 30%, trong khi với một team toàn Senior Developer thì tiêu chí đó gần như bằng 0 và "khả năng đưa vào CI/CD" mới là thứ nặng ký. Cùng một bảng điểm gốc, nhưng thay bộ trọng số là kết quả có thể đảo ngược hoàn toàn. Đó là lý do bạn không thể copy quyết định của công ty khác về áp cho mình.

Bản chất kiến trúc của hai công cụ

Trước khi so sánh, phải hiểu vì sao chúng khác nhau đến vậy — sự khác biệt bắt nguồn từ triết lế thiết kế:

JMeter ra đời năm 1998, là ứng dụng Java desktop có GUI. Nó được thiết kế theo hướng "kéo thả cấu hình" — bạn xây test plan bằng cách thêm các thành phần (Thread Group, Sampler, Listener...) qua giao diện, không cần viết code. Mô hình luồng của nó là thread-based: mỗi virtual user (VU) là một thread thật của hệ điều hành. Điều này trực quan nhưng tốn RAM: một máy thường chỉ chịu được vài trăm tới khoảng một, hai nghìn VU trước khi phải dùng distributed testing.

k6 ra đời năm 2017, do Load Impact (nay thuộc Grafana Labs) phát triển. Nó là công cụ dòng lệnh, viết script bằng JavaScript, chạy trên nhân Go. Mô hình luồng của nó là event-loop / goroutine-based: VU không phải thread hệ điều hành mà là các đơn vị nhẹ do Go quản lý. Nhờ vậy một máy k6 có thể mô phỏng hàng chục nghìn VU với RAM khiêm tốn hơn nhiều. Đổi lại, bạn bắt buộc phải viết code — không có GUI để kéo thả.

Hiểu hai gốc rễ này, mọi khác biệt còn lại đều suy ra được một cách logic.

Bảy tiêu chí cốt lõi của ma trận

Dưới đây là bảy tiêu chí tôi khuyên dùng cho hầu hết dự án. Bảng điểm mang tính định hướng (thang 1–5, 5 là tốt nhất), bạn sẽ tự điều chỉnh theo bối cảnh.

Về giao thức — đây thường là tiêu chí "phá vỡ thế cân bằng". Nếu bạn cần test trực tiếp database qua JDBC, test message queue qua JMS, hay các giao thức doanh nghiệp cũ như LDAP, FTP, SOAP — JMeter gần như là lựa chọn mặc định vì hỗ trợ sẵn. k6 mạnh và hiện đại nhưng chủ yếu xoay quanh HTTP, WebSocket, gRPC; muốn đụng tới thứ khác bạn phải tìm hoặc tự viết xk6 extension.

Về CI/CD và version control — đây là nơi k6 tỏa sáng. Vì script k6 chỉ là file .js, nó nằm chung repo với source code, được review qua pull request như code bình thường, dễ diff, dễ tái sử dụng module. File .jmx của JMeter là XML dài dòng — hai người sửa cùng lúc là xung đột merge kinh hoàng, và reviewer gần như không đọc nổi diff.

Về khả năng mở rộng quy mô — nếu bạn cần mô phỏng 50.000 người dùng đồng thời, k6 làm được trên một máy tầm trung, còn JMeter buộc bạn dựng cả cụm master/slave với chi phí vận hành cao hơn hẳn.

Một sự thật ít người nói: không phải chọn một

Điều quan trọng cần gỡ bỏ ngay từ đầu: quyết định không nhất thiết là "chọn một, bỏ một". Nhiều tổ chức trưởng thành dùng cả hai cho những mục đích khác nhau — k6 cho các smoke test và performance gate chạy trong CI mỗi lần deploy, JMeter cho các bài test giao thức phức tạp hoặc các kịch bản mà team QA truyền thống đã quen. Ma trận giúp bạn phân định "công cụ nào cho loại việc nào", chứ không ép bạn về một phe.

Tình huống thực tế

Tình huống 1 — Tiki và bài toán chuẩn hóa cho CI/CD

Giả định một team platform tại một sàn thương mại điện tử lớn như Tiki. Họ deploy nhiều lần mỗi ngày theo mô hình microservices, dùng GitLab CI. Yêu cầu của họ rất rõ: mỗi khi một service checkout được merge, phải có một performance gate tự động chạy — nếu p95 latency vượt 800ms hoặc error rate vượt 1%, pipeline phải fail và chặn deploy.

Team này gồm các SDET (Software Development Engineer in Test) đều thạo JavaScript. Khi dựng ma trận, họ đặt trọng số cao cho "tích hợp CI/CD" (35%), "version control" (25%), "hiệu năng VU" (15%), và gần như bằng 0 cho "thân thiện với non-dev" vì cả team đều code được. Kết quả: k6 thắng áp đảo. Threshold của k6 map trực tiếp thành exit code khác 0, GitLab CI hiểu ngay là fail — không cần parse XML báo cáo như với JMeter. Script checkout.js nằm cùng repo service, review qua merge request.

Bài học rút ra: khi công cụ phải sống bên trong pipeline và team đã biết code, khả năng "chạy headless trả exit code" và "được version như code" quan trọng hơn mọi thứ. Đây là sân nhà của k6.

Tình huống 2 — Ngân hàng và bài toán test qua nhiều giao thức

Giả định một ngân hàng tầm trung tại Việt Nam cần kiểm thử hệ thống core banking trước đợt nâng cấp cuối năm. Bối cảnh: hệ thống có phần API REST hiện đại, nhưng phần lõi giao dịch vẫn chạy qua JMS message queue để xử lý bút toán, và một số truy vấn báo cáo đánh trực tiếp vào Oracle qua JDBC. Team kiểm thử chủ yếu là QA có nhiều năm kinh nghiệm nhưng không phải dev — họ quen dùng công cụ có giao diện.

Khi họ dựng ma trận, hai tiêu chí "độ phủ giao thức" (30%) và "thân thiện với non-dev" (25%) chiếm phần lớn trọng số. JMeter thắng rõ rệt: nó có JMS Publisher/Subscriber Sampler và JDBC Request Sampler sẵn dùng, cấu hình qua GUI, không cần ai viết Groovy nếu kịch bản đơn giản. Nếu ép dùng k6, họ sẽ phải săn tìm hoặc tự build xk6 extension cho JMS — rủi ro và tốn thời gian cho một team không mạnh về lập trình.

Bài học rút ra: một tiêu chí "cứng" như giao thức có thể lấn át tất cả tiêu chí "mềm". Dù k6 hiện đại hơn, nó không phải công cụ cho bài toán đa giao thức doanh nghiệp cũ. Đừng để sự hào nhoáng của công cụ mới che mờ yêu cầu kỹ thuật thực tế.

Tình huống 3 — Startup fintech và quyết định "dùng cả hai"

Giả định một startup fintech Đông Nam Á, quy mô khoảng 15 kỹ sư, sản phẩm là ví điện tử. Ban đầu họ nghĩ phải chọn dứt khoát một công cụ để "gọn". Nhưng khi làm ma trận nghiêm túc, họ nhận ra hai loại nhu cầu tách bạch: (1) test hồi quy hiệu năng nhẹ, chạy mỗi lần merge trên GitHub Actions; và (2) test tải toàn diện mô phỏng ngày lễ, do một bạn QA lead không rành code phụ trách.

Thay vì gồng chọn một, họ chấp nhận portfolio hai công cụ: k6 cho nhu cầu (1) — nhanh, headless, nằm trong CI; JMeter cho nhu cầu (2) — QA lead tự dựng kịch bản qua GUI, chạy các đợt soak dài ngày. Chi phí học của cả team không tăng nhiều vì mỗi công cụ chỉ do đúng nhóm người phù hợp dùng.

Bài học rút ra: ma trận không phải lúc nào cũng cho ra một người thắng duy nhất. Đôi khi kết quả đúng là "phân vai": mỗi công cụ đảm nhận đúng phần nó mạnh nhất. Người ra quyết định giỏi biết khi nào nên tối ưu cho sự đơn giản (một công cụ) và khi nào nên chấp nhận hai công cụ để mỗi việc được làm bằng công cụ phù hợp.

Hướng dẫn từng bước

Đây là quy trình bạn có thể áp dụng cho bất kỳ dự án nào để ra quyết định có cơ sở, thay vì tranh cãi cảm tính.

Bước 1 — Liệt kê ràng buộc thực tế của dự án. Trả lời thành thật: Team gồm ai, có biết code không? Cần test những giao thức nào? Có pipeline CI/CD không, dùng gì? Cần bao nhiêu VU tối đa? Có ngân sách cho công cụ trả phí (như cloud) không? Viết ra giấy — đây là dữ liệu đầu vào của mọi quyết định.

Bước 2 — Chọn tiêu chí và gán trọng số. Lấy bảy tiêu chí ở trên làm khung. Phân bổ trọng số sao cho tổng bằng 100%. Nguyên tắc: trọng số phản ánh ràng buộc ở Bước 1, không phải sở thích cá nhân. Nếu giao thức là vấn đề sống còn, cho nó trọng số cao; nếu không đụng gì ngoài HTTP, cho nó thấp.

Bước 3 — Chấm điểm từng công cụ trên mỗi tiêu chí. Dùng thang 1–5. Có thể dựa vào bảng gợi ý trong bài nhưng hãy điều chỉnh theo kinh nghiệm thực tế của team. Ghi kèm một câu lý do cho mỗi điểm — chính phần "lý do" này mới là thứ bạn dùng để bảo vệ quyết định về sau.

Bước 4 — Tính điểm có trọng số. Với mỗi công cụ, nhân điểm từng tiêu chí với trọng số rồi cộng lại. Ví dụ tiêu chí CI/CD trọng số 0.35, k6 được 5 điểm thì đóng góp 1.75. Cộng hết bảy tiêu chí ra tổng điểm mỗi công cụ.

Bước 5 — Kiểm tra "deal-breaker". Trước khi công bố, xét lại: có tiêu chí nào mà một công cụ bị điểm quá thấp đến mức không thể chấp nhận, bất kể tổng điểm? Ví dụ nếu bạn bắt buộc test JMS mà k6 không hỗ trợ, thì dù k6 thắng tổng điểm, giao thức vẫn là điểm chặn. Deal-breaker luôn ưu tiên hơn tổng điểm.

Bước 6 — Ghi lại quyết định và lý do. Viết một đoạn ngắn: "Chọn X vì..., trong bối cảnh Y. Sẽ xem lại nếu Z thay đổi." Tài liệu này cực kỳ quý khi sáu tháng sau có người mới vào hỏi "sao mình dùng cái này?".

Lỗi thường gặp & mẹo

Lỗi 1 — Chọn theo trào lưu, không theo bối cảnh. Thấy các bài blog khen k6 hiện đại rồi ép cả team QA thủ công học JavaScript trong tuyệt vọng. Hoặc ngược lại, bám JMeter vì "quen" dù cả team đều là dev và pipeline CI đòi headless. Mẹo: luôn quay lại danh sách ràng buộc ở Bước 1, để dữ kiện quyết định thay vì cảm xúc.

Lỗi 2 — Bỏ qua chi phí bảo trì dài hạn. Nhiều người chỉ so "dựng test nhanh không" mà quên hỏi "sáu tháng sau ai sửa test này?". File .jmx nhìn dựng nhanh nhưng khi phình to và cần nhiều người cùng sửa thì trở thành ác mộng version control. Mẹo: luôn cân nhắc tiêu chí "bảo trì & review" ngang hàng với "dễ khởi động".

Lỗi 3 — Coi trọng số là cố định vĩnh viễn. Ma trận phản ánh bối cảnh tại một thời điểm. Team tuyển thêm dev, hệ thống thêm giao thức mới, chuyển sang CI/CD — mọi thứ đổi thì trọng số phải đổi. Mẹo: ghi rõ điều kiện "sẽ xem lại nếu..." trong tài liệu quyết định.

Lỗi 4 — Nhầm "không có GUI" là "khó hơn tuyệt đối". Với dev, viết script k6 nhiều khi nhanh hơn kéo thả trong JMeter, và dễ tái sử dụng hơn. GUI là lợi thế với non-dev, nhưng là gánh nặng với người quen code. Mẹo: đánh giá GUI theo người dùng thật, đừng mặc định GUI luôn tốt.

Mẹo tổng quát: khi bí, hãy làm một spike nhỏ — cho hai người, mỗi người dựng thử cùng một kịch bản đơn giản bằng một công cụ trong nửa ngày, rồi so sánh trải nghiệm thật. Nửa ngày thử nghiệm đáng giá hơn hàng giờ tranh luận trên lý thuyết.

Bài tập thực hành

• Dựng ma trận cho chính công ty bạn. Lấy bảy tiêu chí trong bài, tự gán trọng số dựa trên bối cảnh team và hệ thống nơi bạn đang làm (hoặc một công ty giả định bạn tự đặt ra). Tính điểm có trọng số cho JMeter và k6, rồi viết một đoạn ba câu giải thích công cụ nào thắng và vì sao.

• Đảo ngược kết quả. Lấy chính ma trận vừa làm, thay đổi bộ trọng số sao cho công cụ thua ở câu 1 giờ thắng. Câu hỏi suy ngẫm: kịch bản thực tế nào khiến bộ trọng số mới này trở nên hợp lý? Bài tập này giúp bạn thấy rõ trọng số quyết định kết quả nhiều đến mức nào.

• Tìm deal-breaker. Viết ra ba tình huống dự án cụ thể mà trong đó một tiêu chí đơn lẻ (ví dụ: bắt buộc test JDBC, cần 100.000 VU, team không ai biết code) đủ sức phủ quyết mọi tiêu chí khác. Với mỗi tình huống, chỉ ra công cụ nào bị loại và tại sao.

• Viết bản ghi quyết định. Soạn một đoạn ngắn theo mẫu ở Bước 6: chọn công cụ nào, trong bối cảnh nào, và điều kiện nào sẽ khiến bạn xem lại. Tưởng tượng bạn đang trình bày cho sếp không rành kỹ thuật — làm sao để họ gật đầu chỉ sau một phút đọc.

Tóm tắt

Chọn giữa JMeter và k6 không phải cuộc thi xem công cụ nào "xịn hơn", mà là bài toán ghép công cụ với bối cảnh. JMeter mạnh khi team thiên về QA thủ công không code, khi cần độ phủ giao thức rộng (JDBC, JMS, FTP, LDAP...), và khi GUI kéo thả là lợi thế. k6 mạnh khi team biết code, khi cần tích hợp CI/CD trả exit code, khi cần version test như code, và khi phải mô phỏng lượng VU rất lớn trên ít máy.

Công cụ ra quyết định là một decision matrix có trọng số: liệt kê tiêu chí, gán trọng số theo ràng buộc thực tế của dự án, chấm điểm, tính tổng, và luôn kiểm tra deal-breaker trước khi kết luận. Nhớ rằng kết quả không nhất thiết là một người thắng — nhiều tổ chức trưởng thành dùng cả hai, mỗi công cụ đúng một vai. Và quan trọng nhất: mọi quyết định đều gắn với một thời điểm và một bối cảnh; khi bối cảnh đổi, hãy dựng lại ma trận. Đó là tư duy của một Performance Engineer thực thụ — không trung thành với công cụ, chỉ trung thành với kết quả.