Xin được nói trước, mình đang học về performance test, không giỏi nên những thứ dưới đây hoàn toàn là kinh nghiệm của mình, bạn chỉ nên đọc để tham khảo.

Và bài viết dưới đây sử dụng Jmeter để thực hiện load test, bạn muốn biết cách sử dụng jmeter thì vào blog này.

I. Mục đích của Load test

Load test là loại test xác định khả năng (capacity) của hệ thống bằng cách tăng dần lượng load (users). (Một sai lầm của mình)

• Theo mình, load test là 1 loại test mà ở đó mình đã biết trước lượng load mà mình sẽ test và expected result. Ví dụ: mình muốn kiểm tra hệ thống có thể đáp ứng được 30 users tương tác đặt mua hàng trong 1 khoảng thời gian 10 phút mà có responsive time trung bình không lớn hơn 3s.

• Việc xác định capacity của hệ thống bằng cách nâng dần lượng load, mình gọi là Capacity test, cũng là 1 dạng của Load Test. Phần hướng dẫn còn lại của bài viết này là Capacity Test.

Lưu ý: Trên đây là cách mình phân biệt giữa 2 kiểu performance test: load và capacity test. Nếu nó không match với những gì người khác nói hoặc hiểu biết của bạn, vui lòng bỏ qua. Mình không có nhu cầu tranh cãi về thuật ngữ.

Thời gian run test từ 10min -> 60min, có người run lâu hơn, đến 2.5h.

Capacity test có 1 số đặc điểm sau đây:

• Max load (Concurrent Users / Transaction) mà hệ thống có thể xử lý trước khi bắt đầu có dấu hiệu hoạt động không bình thường. Thế nào là không bình thường? Đọc thêm phần phân tích report ở phía dưới.
• Client-side Metrics: Active Threads, Throughput, Response Time
• Server-side Metrics: CPU Utilization, Memory consumption.

II. Cách tạo script

Ở bài này, mình đã có nói về cách tạo script của Capacity test, nó phụ thuộc vào bạn có bao nhiêu scenario, mỗi scenario sẽ tương đương với 1 test script riêng.

Tóm tắt lại, tạo script gồm có nhiều bước nhỏ, gộp thành 2 bước chính:

1. Record User Actions: dùng chức năng record để có thể capture được toàn bộ các request
2. Modification: Sửa lại các tham số của request để script run lại không còn lỗi.

III. Cách config Thread group

• Number of Thread / Users / Virtual Users: đôi khi được gọi là CCU (Concurrent User), là số User giả lập để tạo lượng load.
• Ramp-up: not Ram-up, hãy nhìn kỹ, đọc kỹ. Đây là thời gian để load generator tạo được đủ số User ở phía trên.
• Duration: là tổng số thời gian test sẽ thực hiện

Trong 3 thông số trên thì Ramp-up là cái mà nhiều người bối rối nhất, điển hình là mình. =)))) Thế cái Ramp-up này config thế nào cho đúng. Theo mình thì sẽ như thế này:

0 < Ramp-up Period <= Duration

Q: Ơ, sếp mình bảo là test 1000 users cùng lúc, thì ramp-up mình nghĩ là bằng 0 chứ nhỉ?

A: Ramp-up là thời gian để cái máy tạo load tạo được đủ lượng users cần thiết, nó là khoảng thời gian để khởi động cho JMeter tạo load và server tiếp nhận load 1 cách từ từ nhằm setup các thứ được chuẩn xác (cache, load balancing, server configuration…) do đó nếu bạn đặt ramp-up = 0 thì có nghĩa là máy tính của bạn có 0s để tạo đủ 1000 Threads. Bạn nghĩ máy bạn có chịu nổi không? Giả sử máy bạn chịu nổi thì cái bạn làm là spike test rồi, không phải load test nữa. (Oh man, đây là lỗi thiếu hiểu biết của mình. Mình sẽ viết 1 bài khác để giải thích đoạn này thật cặn kẽ)

Q: Thế mình chọn con số nào, khoảng 0 –> Duration cũng rất dài?

A: Ở trên trang Jmeter người ta có nói như sau:

Ramp-up needs to be long enough to avoid too large a work-load at the start of a test, and short enough that the last threads start running before the first ones finish (unless one wants that to happen).

Mình đã suy nghĩ về hướng dẫn của họ khá nhiều, cũng làm thử như vậy nhưng khi làm thì khó khăn trong việc tìm capacity của hệ thống. (lý do vì sao mình sẽ giải thích trong khóa học Jmeter) Sau khi thử nhiều con số khác nhau thì mình nghĩ là nên thử bắt đầu với Ramp-up = Duration. Đồ thị Thread group sẽ như thế này:

Nếu bạn kéo con số Ramp-up nhỏ dần thì đồ thị sẽ như thế này.

Chốt lại, theo mình thì tỷ lệ này sẽ ổn: 2/3 duration <= Ramp-up <= Duration

Vì sao mình lại chọn Ramp-up dài như vậy? vì mình hi vọng sẽ tìm được capacity trên 1 điểm nào đó ở sườn thoải của đồ thị. Ví dụ, khi thời điểm 11:51 thì phát hiện throughput ko tăng lên được nữa, thời điểm này tương ứng với 50 active threads.

IV. Cách run test

Run test là việc nhiều người hay nghĩ, bấm nút cái là xong. =))) nhưng mà đâu biết là testers còn đang đau đầu suy nghĩ “run với thông số mỗi lần là bao nhiêu, làm thế nào để biết tăng hay giảm Threads“

Khi bạn nhận được yêu cầu “test 1000 users cùng lúc” từ ai đấy. Hãy mạnh dạn… vứt bỏ cái yêu cầu đó sang 1 bên vì cái hệ thống bạn đang làm chưa chắc nó đã chịu nổi 100 users đâu. 😀 nói thật, không giỡn, đừng ảo tưởng.

Vì Capacity test là tăng dần lượng load nên bạn phải run rất nhiều lần, tăng load lên chậm rãi –> bấm nút cái là không xong đâu, phải bấm cả mấy chục lần đấy. =)))))

Mình thường làm theo kiểu như thế này:

• Run lần 0: Để biết là script mình đã làm đúng. Threads=1, Ramp-up=1, loop=1
• Run lần 1: Threads=10, Ramp-up=300, Duration=300 ( Phân tích report, dự là app vẫn ngon :D)
• Run lần 2: Threads=30, Ramp-up=600, Duration=600 (Phân tích report, nếu ngon thì tăng tiếp)
• Run lần 3: Threads=60, Ramp-up=1500, Duration=1800
• Run lần 4: Threads=100, Ramp-up=1500, Duration=1800
• Run lần 5: Threads=150, Ramp-up=1500, Duration=1800
• …. Chỉ tăng mỗi Threads
• Run lần xxx: Thread = lần trước, Ramp-up=3600, Duration=3600

Lưu ý:

• Sẽ chẳng có công thức đúng cho việc run test, chỉ có pattern là tăng dần lượng load. Dễ nhất là bạn cố định duration, cố định ramp-up, chỉ thay đổi Threads.
• Test với nhiều khoảng thời gian khác nhau, có người thì nói chỉ cần run 10min, nhưng mình nghĩ để ổn định thì mình sẽ run đến duration = 1h, đấy là mình nghĩ thôi, còn gần như là mình chỉ run tầm 15min, hoặc cùng lắm là 30min
• Ramp-up bạn cũng điều chỉnh với nhiều thời điểm khác nhau, nhưng đừng ngắn quá vì cái điểm max load của hệ thống sẽ xuất hiện ở chỗ sườn dốc (tăng dần) của đồ thị active threads. Sườn dốc thoải sẽ dễ nhìn hơn sườn dốc thẳng đứng. (đã giải thích ở trên)

V. Cách phân tích report

Cuối cùng, sau khi run test, ta phải đưa ra được kết luận là capacity của hệ thống với scenario này là bao nhiêu?

• Bao nhiêu Transaction / Request trên 1 đơn vị thời gian (phút hoặc giây)

Để biết được cái đấy, ta phải nhìn vào đồ thị report của từng lần run, nhưng nói chung là sẽ có dấu hiệu bất bình thường sau đây:

• Khi User tăng dần thì throughput cũng tăng, nhưng đến 1 điểm nào đấy throughput không thể tăng lên nữa, response time chuyển thể từ tăng nhẹ sang tăng nhanh, hoặc bắt đầu có error xuất hiện.

Nếu run mà User tăng, throughput tăng, hết thời gian test mà throughput không có dấu hiệu ngừng tăng thì tiếp tục tăng lượng load lên test tiếp.

Khi mà throughput không tăng lên được nữa thì ta có thể xác định được lượng Max load:

Ví dụ như hình trên thì ta có thể tạm kết luận được:

• Throughput là 40 Request/sec
• ~ 85 Concurrent Users

Tất nhiên, bạn nên xem xét cả Response time và Error rate và các chỉ số của Server Metrics nữa:

Bạn muốn có đồ thị như mình làm ở trên thì follow các bài viết này:

• Monitor các thông số của Jmeter
• Lấy thông số server
• Lấy thông số MySQL

Kết luận:

Sẽ có nhiều thứ phải học về performance testing, mình cũng chỉ biết chút ít, rất hi vọng việc “biết đến đâu, viết đến đấy” giúp ích cho bạn nào phải làm Capacity test. 😀