Giới thiệu một số thành phần của jmeter và tạo test plan đầu tiên trong jmeter

jmeter May 23, 2022

Phần 1. Giới thiệu về Performance Testing

Performance Testing: Là 1 kiểu test để đo lường hệ thống hoặc ứng dụng đưa ra các thông số, tiêu chí về response time, throughput… từ đó đánh giá hiệu năng của hệ thống

- Response time: Thời gian phải hồi của request (tổng thời gian gửi request từ client đến server và thời gian server trả kết quả về phía client) => cho biết request đang được xử lý nhanh hay chậm -> càng thấp càng tốt vì trả về data nhanh hơn

- Throughput : Số request cùng xử lý đồng thời trong 1 đơn vị thời gian.

Ví dụ:

+ 100 RPS (Request per second): Server xử lý được 100 request/giây

+ 1000 RPM (Request per minutes) : server xử lý được 1000 request/phút

Một số đơn vị khác như: QPS (queries), TPS (Transitions)

Performance Testing bao gồm:

- Load testing: Là 1 kiểu test giúp đánh giá hành vi của hệ thống bằng cách gia tăng lượng tải (ví dụ như: gia tăng số lượng user đồng thời truy cập, số lượng request) để xem hệ thống của mình có thể xử lý được bao nhiêu tải. Con số có thể xử lý được gọi là Capacity.

Ví dụ: Ta test hệ thống với số lượng là 100 user, không thấy có lỗi, không thấy có dấu hiệu bị overload, response trả về không bị lâu, hệ thống hoạt động bình thường => Ta tiếp tục tăng số lượng user lên 200, 400,800 vẫn không thấy có lỗi, hệ thống vẫn hoạt động bình thường => Ta tiếp tục tăng số lượng user lên đến 1500, response time trả về bị lâu lên đến vài giây => Ta giảm xuống 1200, 1100,... Cứ tăng và giảm cho tới 1 mức nào đó, nếu dưới mức đó hệ thống hoạt động bình thường, ko có 1 vấn đề nào hết nhưng ngay trên mức đó, hệ thống của mình bắt đầu có lỗi (response time tăng cao, overload) -> mức đó được gọi là Capacity.

=> Việc test nâng tải lên xuống như vừa làm gọi là Load testing

- Stress Testing: Dùng để đánh giá hệ thống tại hoặc bên trên điểm Limit (Capacity) để tìm thấy Breaking point của hệ thống

Ví dụ: Ta tìm được Capacity của hệ thống là 1000(từ load test) thì ta sẽ test tại điểm 1000, rồi nâng lên 1200, 1500, 1800, 2000… Qua ngưỡng Capacity thì sẽ có dấu hiệu bị lỗi => mục đích của stress testing sẽ là nâng lượng load đó lên để xem thử lỗi (nếu có) nó sẽ ra tăng như thế nào, và đến 1 mức nào đó thì hệ thống ko thể xử lý được nữa (bị timeout) gọi là Breaking point

Một mục đích khác của stress testing là test khả năng recovery của hệ thống. Khi hệ thống bị breaking point thì chắc chắn sẽ cần phải restart server hoặc có cơ chế để tự động restart => Vậy sau khi restart xong thì hệ thống của mình có còn hoạt động được bình thường ko hay sẽ bị ảnh hưởng tới performance ví dụ như chạy chậm,.. Test khi server được restart lại thì được gọi là recovery.

Spike testing: Test lượng tải lớn trong 1 khoảng thời gian ngắn

ví dụ: Mỗi tháng shopee sẽ có 1 ngày tung ra voucher => thời gian để bạn có thể lấy được mã này chỉ tầm 5-10 phút và số lượng người dùng vào săn voucher cũng là rất lớn

Endurance Testing: Ngược lại với spike testing nó sẽ test với một lượng tải thấp và trong khoảng thời gian dài

Volume Testing: test với một lượng data rất lớn có thể lên đến hàng triệu bản ghi

Ví dụ: Cùng một câu query nhưng:

  • Khi ít data thì thời gian xử lý nhanh
  • Khi lên đến hàng triệu data thì thời gian xử lý lâu

Chúng ta sẽ so sánh thời gian trong 2 trường hợp này
Phần 2. Giới thiệu Jmeter

Các thành phần phổ biến trong Jmeter:

Các thành phần được giới thiệu trong bài viết này sẽ là:

  • Thread Group
  • Sampler
  • Listeners
  • Configuration














1. Launching

Có 2 mode để mở Jmeter:

  • UI mode: Dùng để viết test plan, để debug test, khi run test thực tế sẽ ko sử dụng mode này (lý do vì sao thì khi mình sẽ nói ở các bài sau)
  • Non UI mode (command line): Dùng để run test

2. Giao diện của Jmeter

Màn hình Default gồm các Button có chức năng:

Giao diện của Jmeter gồm có:

  • Thanh button, gồm các button như: run test, clear result, button search,... . Có thể xem chi tiết ở https://jmetervn.com/2016/09/30/the-shortcuts-in-jmeter/
  • Chỉ có thể tạo duy nhất 1 test plan, bên dưới test plan là tất cả các phần tử của test plan => tạo ra cái gì thì nó nằm ở đây
  • Khi click vào các phần tử của test plan  thì sẽ hiển thị phần configuration ở bên tay phải

Muốn add thêm phần tử nào thì chọn Test plan => Add => chọn phần tử muốn add
3. Thread Group

Cách tạo Thread Group: Click chuột phải vào Test plan => Add => Threads (Users) => Thread Group

- Mỗi test plan bắt buộc phải có 1 Thread group. Một test plan có thể có nhiều thread group và bắt buộc phải có một thread group. Các request bắt buộc phải tạo ra dưới thread group

- Thread group đại diện cho 1 group các action và 1 group các user. Có thể hiểu như là 1 bộ test suite, trong đó có chứa các request

- Một số thông số cần chú ý trong Thread Group:
+ Number of Threads: Mỗi Thread đại diện cho một người dùng ảo, JMeter cho phép thay đổi số lượng người dùng không hạn chế để thực hiện các thử nghiệm.
+ Ramp-Up Period: Thời gian để Jmeter tạo ra tất cả những thread cần thiết

+ Loop Count: Số lần lặp lại những yêu cầu của người dùng.
4. Sampler

- Là phần core của Jmeter

- Cách tạo Sampler: Click chuột phải vào Thread Group => Add => Sampler => chọn bất kỳ Sampler bạn muốn

- Jmeter support rất nhiều loại protocol, thông dụng nhất là HTTP request.

Chú ý:

  • server name: sau dấu //
  • Path: sau dấu / đầu tiên

Chúng ta sẽ demo với 1 HTTP request

- Step 1: Click chuột phải vào Thread Group => Add => Sampler => HTTP Request

- Step 2: Config HTTP request

Ví dụ muốn test trang chủ của Jmeter : https://jmeter.apache.org ta config như sau:

+ B1:  Đổi tên request mình mong muốn để phân biệt với những Request khác

+ B2: Nhập Protocol là https (mặc định là HTTP, nên nếu là HTTP thì không cần điền vào đây)

+ B3: Nhập Server name or IP là jmeter.apache.org

+ B4: Do Port: HTTP (80), HTTPS (443) -> default và không cần phải nhập. Khi sử dụng url khác có dạng example.com:8080/…phải nhập Port = 8080

+ B5: Do link không có Path nên bỏ trống


- Một số Sampler cần chú ý:
+ FTP Request: Test file server
+ HTTP Request: Test WEB HTTP, HTTPS
+ JDBC Request: Test Database
+ LDAP Request: Hệ thống xác thực User
+ Mail request: Test Mail server

5. Listeners

- Cho phép view kết quả test dưới dạng bảng biểu, đồ thị, cây...Listeners sẽ cung cấp một cách trực quan những dữ liệu thu được.

- Cách tạo: Click chuột phải Test plan/ thread group/ request => Add => Listener => Chọn dạng kết quả

- Một số dạng phổ biến như sau:

+ View Results Tree: Cho phép theo dõi thông tin của dữ liệu mà server trả về cho mỗi người dùng dưới các dạng khác nhau: Cụ thể như text hay json …vv

+ Graph Results: Trả về đồ thị biểu diễn những thông số về số lượng yêu cầu, lượng yêu cầu được xử lý mỗi phút, giá trị trung bình, giá trị trung vị của toàn bộ thời gian phản hồi từ server.

+ Summary Report: Cung cấp báo cáo về các giá trị thời gian phản hồi thấp nhất/cao nhất, số yêu cầu xảy ra lỗi, lưu lượng trung bình.

Ta sẽ demo với 1 dạng phổ biến, hay được sử dụng nhất là View Results Tree

Click chuột phải Test Plan => Add => Listener =>View Results Tree

View result tree có thể tạo được ở nhiều level, tạo ở ngay dưới test plan, đứng ở thread group cũng có thể tạo view result tree, đứng ở request cũng có thể tạo => nằm ở level nào thì sẽ hiển thị kết quả ở level đó.
6. Configuration

Configuration dùng để thiết lập các giá trị mặc định và các biến để sử dụng sau này bởi các samplers.
- Cách tạo: Click chuột phải Test plan/ thread group/ request => Add => Config Element => Chọn dạng kết quả

- Một số dạng phổ biến như sau:
+  HTTP request default
HTTP request default cho phép đặt các giá trị mặc định mà bộ điều khiển HTTP Request của bạn sử dụng.
Ví dụ: Bạn đang gửi 100 yêu cầu HTTP đến máy chủ google.com. Bạn sẽ phải nhập thủ công tên máy chủ = google.com cho tất cả 100 yêu cầu này. Thay vào đó, bạn có thể thêm một HTTP request defaults với trường "Tên máy chủ hoặc IP" = google.com. Không cần gõ 100 lần!

+ HTTP User Defined Variables
HTTP User Defined Variables cho phép khởi tạo cái biến với giá trị mong muốn. Để gọi đến giá trị đó ta sử dụng lệnh ${Tên biến}

Ví dụ: Bạn đang gửi 100 yêu cầu HTTP đến máy chủ google.com. Bạn sẽ phải nhập thủ công tên máy chủ = google.com cho tất cả 100 yêu cầu này. Thay vào đó, bạn có thể thêm một HTTP request defaults với trường "Tên máy chủ hoặc IP" = google.com. Không cần gõ 100 lần!. Nhưng lúc này chưa tối ưu vì có thể trong quá trình làm domain có thể bị thay đổi, chính vì vậy ta sẽ tạo biến và gán giá trị cho nó. Sau này ta muốn thay đổi ta chỉ cần vào thay đổi giá trị của nó mà không cần thay đổi nhiều chỗ.

Cách thức hoạt động:

HTTP User Defined Variables sẽ khởi tạo biến => thực hiện gán biến và truyền giá trị cho HTTP request default => Gọi đến các request con và thực hiện run => trả về kết quả

Tags

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.