Seri này mình bắt đầu viết từ việc mình đang bắt đầu tự học và mong muốn có thể apply test performance test cho dự án đang làm trên công ty. Mình hoàn toàn chưa có kinh nghiệm với nó, nên các bài viết trong seri này sẽ đến từ việc tự tổng hợp các kiến thức trên internet mà mình tự tìm hiểu được. Mình chọn Jmeter vì nó phổ biến và khi nhắc đến performance test là người ta hay nhắc đến tool này. Ok let’s get started.
Performance Testing là gì ? Lợi ích của nó là gì ?
Thật sự mà nói mình cảm thấy việc kiểm thử hiệu năng ( Performance testing ) có vẻ như không được quan tâm so với unit test, system test, functional test… nhưng loại kiểm thử mà các công ty, tổ chức đã quá quen thuộc và đã có quá nhiều kinh nghiệm. Mình thực sự quan tâm đến hiệu năng của một app, nhưng khi mình đưa ra một vấn đề đại loại như: “ê, em cảm thấy cái app của mình nó xử lí chậm vđ” hoặc “có vài cái ảnh mà upload một phút chưa xong vậy” thì đều được nhận được câu trả lời kiểu “anh thấy cũng chấp nhận được mà” hoặc “do server phải xử lý abc”, nhưng mình không thể lấy được một số liệu cụ thể chậm bao nhiêu giây, phản hồi của hệ thống như nào. Nên mình thực sự quyết tâm khi bắt đâu seri này.
Quay trở lại Performance Testing là gì ? Trước khi trả lời câu hỏi này, chúng ta có bao giờ tự hỏi vậy một ứng dụng có hiệu năng tốt là thế nào, theo mình nghĩ nó chính là trải nghiệm của người dùng với ứng dụng. Nếu tôi có thể làm trải nghiệm app mà không có độ trễ nào ( ví dụ load một page không bị khựng, không bị blank page, không phải chờ quá lâu để load trang… ) đó chính là một ứng dụng có performance tốt. Nó không làm cho khách hàng cảm thấy khó chịu và chỉ xóa app không bao giờ dùng đến nữa.
Vậy Performance test là gì ? Các thông số ta cần đo lường trong performance có thể chia làm 2 kiểu: các chỉ số liên quan đến server và các chỉ số liên quan đến hiệu năng.
Server-oriented indicators: Các chỉ số này liên quan trực tiếp đến hiệu năng và hoạt động của máy chủ, bao gồm khả năng phản hồi và chịu tải:
- Thời gian phản hồi (Response time): Thời gian từ khi yêu cầu được gửi đến khi nhận phản hồi.
- Thời gian tải trang (Page load time): Thời gian từ lúc gửi yêu cầu đến khi tải xong trang web.
- Số lượng người dùng đồng thời (Concurrent users): Số lượng người dùng có thể tương tác đồng thời với hệ thống.
- Khả năng chịu tải (Capacity): Khả năng của hệ thống để chịu tải và duy trì hiệu suất.
- Tỷ lệ lỗi (Error rate): Tỷ lệ phần trăm yêu cầu gây ra lỗi trong tổng số yêu cầu.
- Tỷ lệ thất bại (Failure rate): Tỷ lệ phần trăm yêu cầu thất bại trong tổng số yêu cầu.
Efficiency-oriented indicators: Các chỉ số này đánh giá mức độ hiệu quả khi sử dụng tài nguyên và tối ưu hóa hiệu năng của hệ thống:
- Số lượng yêu cầu tối đa (Maximum throughput): Số lượng yêu cầu tối đa hệ thống có thể xử lý trong một đơn vị thời gian.
- Tốc độ xử lý (Processing speed): Tốc độ mà máy chủ hoặc hệ thống xử lý yêu cầu.
- Mức độ sử dụng tài nguyên (Utilization): Mức độ mà hệ thống tận dụng tài nguyên (CPU, bộ nhớ, băng thông mạng).
Performance Standards
Nếu bạn hi vọng sẽ có một bảng tiêu chuẩn để so sánh thế nào là một ứng dụng “good” or “bad” thì có lẽ câu trả lời sẽ làm bạn thất vong. Cái này là mình đọc được trong cuốn ” The Art of Application Performance Testing” mọi người có thể tham khảo, research này được thực hiện vào cuối những năm 80 của thế kỉ 20 dành cho những ứng dụng nhập văn bản thời kì đó, nhưng có lẽ nó vẫn có thể tham khảo được.
- Quy tắc 15s ( Greater than 15 seconds ): Quy tắc này được hiểu đơn giản nếu một tác vụ mà user mà phải chờ hơn 15s để nhận được response của hệ thống thì tốt nhất hệ thống nên được thiết kế sao cho người dùng có thể chuyển sang hoạt động khác và yêu cầu nhận phản hồi vào một thời điểm sau đó.
- Quy tắc 4s ( Greater than 15 seconds ): Nếu một ứng dụng mất hơn 4 giây để phản hồi, người dùng có thể bắt đầu cảm thấy bực bội hoặc không kiên nhẫn, vì nó gây gián đoạn trong quá trình suy nghĩ hoặc công việc của user.
- 2-4s: Delay của hệ thống trong khoảng 2-4s là một ngưỡng mà user có thể chấp nhận trong các tình huống mà họ không quá tập trung vào tác vụ đó, nhưng lại có thể gây khó chịu khi họ đang ở giai đoạn quan trọng của quá trình thực hiện tác vụ. ví dụ như: khi tôi input thông tin thẻ tín thì oke tôi có thể chờ vài (s) để verify thông tin thẻ của tôi, nhưng nếu bắt tôi chờ 5s để mở màn chi tiết sản phẩm tôi muốn mua thì đó có thể gây khó chịu, kiểu kiểu thế.
- Quy tắc 2s: Đối với các tác vụ yêu cầu user phải nhớ để phản hồi lại hệ thống thì require của hệ thống phải là dưới 2s
- Dưới 1s ( Subsecond response time ) : với các tác vụ liên quan đến viết vẽ cần sự tương tác ngay lập tức thì yêu cầu về phản hồi của hệ thống là dưới một s
- Phần trăm giây ( Deci-second response time ): với những tác vụ kiểu như bấm chuột trái, chuột bải, bổi đen, ctrl paste,… đều yêu cầu phản hồi lập tưc
Từ các rules trên có thể thấy mức 2s là mức có thể chấp nhận được với hầu hết các task vụ, lớn hơn thời gian này chắc chắn sẽ đem lại trải nghiệm không tốt cho người dùng.
Các loại Performance Test
- Load Test: Đo lường khả năng của hệ thống khi chịu tải thông thường hoặc tải cao hơn một chút so với dự kiến. Ví dụ về ngưỡng của hệ thống: Hệ thống chịu được 5k (5000) request và không xảy ra lỗi. Quá 5k sẽ bắt đầu có lỗi, response time bị chậm và sẽ có issue xảy ra. Vậy thì 5k là ngưỡng server có thể hoạt động ổn định.
- Stress Test: Xác định giới hạn của hệ thống bằng cách tăng dần tải vượt xa mức dự kiến cho đến khi hệ thống hỏng để tìm ra breaking point (ngưỡng mà hệ thống sẽ chết) của hệ thống (làm cho hệ thống die mà không response được nữa). Ví dụ về breaking point: 5k thì hoạt động ổn, 7k là bắt đầu có issue, 10k là chết hẳn. Vậy 10k là breaking point.
- Spike Test: Đánh giá khả năng của hệ thống khi đối mặt với các đột biến ngắn hạn, như khi số lượng người dùng tăng đột ngột trong một khoảng thời gian ngắn. Ví dụ số lượng tăng cao đột biến ở trang web thương mại điện tử trong ngày black friday.
- Volume Test: Xác định xem hệ thống có thể xử lý một lượng dữ liệu lớn hay không. Kiểm thử này thường liên quan đến việc đưa vào hệ thống một lượng dữ liệu lớn để kiểm tra xem nó có thể xử lý và duy trì hiệu suất như mong đợi khi có nhiều dữ liệu.
- Scalability Test: Đánh giá khả năng mở rộng của hệ thống khi tăng số lượng người dùng hoặc khối lượng công việc, hỗ trợ cho việc lập kế hoạch bổ sung dung lượng cho hệ thống. Kiểm thử này giúp xác định xem hệ thống có thể mở rộng theo nhu cầu gia tăng hay không, cũng như tối ưu hóa tài nguyên để cải thiện hiệu năng khi số lượng yêu cầu tăng lên.
- Endurance Testing / Soak Testing : Kiểm tra tính ổn định của hệ thống khi hoạt động liên tục trong một thời gian dài. Trong kiểm thử này, hệ thống chịu tải liên tục trong nhiều giờ hoặc nhiều ngày để phát hiện các vấn đề như rò rỉ bộ nhớ, suy giảm hiệu năng hoặc sự cố lâu dài khi tải vẫn duy trì ở mức cao.
- Capacity Testing : Xác định tổng công suất tối đa mà hệ thống có thể xử lý. Loại kiểm thử này giúp tìm ra giới hạn của hệ thống về số lượng người dùng hoặc lượng công việc mà hệ thống có thể xử lý trước khi hiệu năng bắt đầu suy giảm.
Tool / Công cụ kiểm thử Performance
Có rất nhiều tool dùng để kiểm thử hiệu năng, nhưng trong seri này mình chọn JMeter vì những lí do sau: free, phổ biến nhiều tài liệu hỗ trợ, các feature đủ để cho chúng ta practice trong học và làm.
Hướng dẫn cài đặt: https://jmetervn.com/2017/02/27/setup-and-install-jmeter/ ( mọi người tham khảo link này )
Giao diện sau khi cài xong sẽ thế này:
Kết luận
Cơ bản trong bài viết đầu cũng chỉ lí thuyết cơ bản, trong những bài viết tiếp theo mình sẽ trình bày cụ thể hơn về JMeter và các ví dụ để apply vào Performance test.