Cách thực hiện load test

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).

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

Load 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 load test, nó phụ thuộc vào bạn có bao nhiêu sceniario, 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

Bạn muốn học cách đặt biến cho mỗi vị trí config thì follow bài bày: https://jmetervn.com/2017/01/09/running-jmeter-in-non-gui-mode/
  • 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, 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.

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. 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

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ì Load 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
  • Test với nhiều khoảng thời gian khác nhau, có người thì nói chỉ cần run 30min, nhưng mình nghĩ để ổn định thì mình sẽ run đến duration = 1h.
  • 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.

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:

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 load test. 😀

16 thoughts on “Cách thực hiện load test

    • Cảm ơn bạn đã theo dõi blog của mình. 😀 Mình làm performance cũng ít nên không dám viết nhiều, sợ hướng dẫn sai cho mọi người.

      • em gà mờ không biết gì đâu, anh viết gì em cũng cho là đúng hết đó ạ, anh cứ viết hết ra đi anh =))

        • Bạn áp dụng cái sai vào project –> kết quả sai –> ảnh hưởng đến tăng lương chứ =)))) ko viết bừa đc.

  1. Em chào anh. Cảm ơn bài viết hữu ích của anh. Em đang bắt đầu với jmeter, em đã run non-guimode và có được Dashboard file. Em chạy lần đầu tiên với t=30_r=120_d=300. Em đang phân tích 3 biểu đồ là Hits Per Second; Response Times Over Time; và Active Threads Over Time
    a.Tại Active Threads Over Time,
    em thấy các mốc time chạy : 21:17:30 thì 26 active
    21:18 thì 30 active; 21:18:30 là 30 active;… cho tới 21:21:00 thì active đã giảm, active là 26.
    b. tại Hits per second: em thấy lúc 21:17 là 27,83 hits
    lúc 21:17:30 là 32,47 hits( đây là mức cao nhất luôn)
    sau mức này biều đồ đi xuống, và có đi lên, nhưng không đạt được mức 32.47 hits.
    cụ thể 21:18 đạt 28.37 hits
    21:18:30 đạt 30.47 hits
    21:20 đạt 31.02 hits
    21:21 đat 3.93 hits.
    c. Response Times Over Time
    giả sử em có function login, click document, click_detail_document, click_logout
    + login function : lúc 21:17 đạt 6626ms =6,6 s
    lúc 21:17:30 đạt 7902ms
    lúc 21:18 là 8946ms
    lúc 21:19 là 9068ms ( cao nhất)
    + click document function:
    lúc 21:17 đạt 4726ms
    lúc 21:18 đạt 9649 ms
    lúc 21:18:30 là 9185ms

    với report dựa vào reponse time, em thấy là không đạt. cần điều chỉnh lại, tìm ngưỡng của sever.
    Nhưng số threads ở đây chỉ là 30—> cần giảm xuống để chạy ?

    Mong anh support. Em cảm ơn.

    • – Tìm ngưỡng của server như thế nào, anh nói rất rõ trong bài viết rồi, em căn cứ lại vào tình huống của em để xác định được Throughput nhé.

      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

      – Response time không đạt là so với goal của em, em có thể giảm Thread và run tiếp –> tìm ra số Threads có thể đảm bảo được response time như mong muốn.

      • Em cảm ơn anh ạ.
        em đã run lại với threads giảm xuống còn 20, nhưng R và D giữ nguyên.
        RECORDING_0303_T20_R120_D300_DASHBOARD_L1
        a.Hits Per Second: lúc 15:05 là 20.63 hits
        lúc 15:05:30 vọt lên 27.7 hits.
        Sau đó 15:06 giảm xuống 14.83 hits.
        b.Active Threads Over Time
        lúc 15:05 đẩy vào 20 active
        c. Response Times Over Time
        function login: lúc 15:05 đạt 14359ms ( help me, với kinh nghiệm của anh, anh có thể chia sẻ cho em hiểu thêm, sao threads đã giảm từ 30 xuống còn 20, mà sao time lại cao thế anh nhỉ)
        lúc 15:05:30 đạt 8162ms
        lúc 15:6 đạt 17722ms
        RUN lần 2 với threads =20 nhưng R,D giảm đi:
        RECORDING_0303_T20_R60_D180_DASHBOARD_L2

        a.Hits Per Second: biểu đồ này rất lạ, nó đẩy request vào rất lạ, từ 15:13 nó đẩy là 13.60 hits
        , lúc 15:13:30 nó đẩy là 29.27 hits
        lúc 15:14: đẩy vào 34,17 hits.
        lúc 15:14:30 nó đẩy vào giảm xuống là 30.83 hits
        Sau đó 15:15 nó đẩy vào giảm xuống 23.63 hits.
        Sau đó 15:15:30 nó đẩy vào giảm xuống 18.23 hits. và cũng kết thúc biểu đồ HIT.

        b.Active Threads Over Time
        lúc 15:13:30 đẩy vào 18active
        15:14 đẩy vào 20 active
        15:14:30 đẩy vào 20 active

        c. Response Times Over Time
        function login: lúc 15:13:30 đạt 6953ms (
        lúc 15:14 đạt 6879ms
        lúc 15:14:30 đạt 7855ms
        lúc 15:15 đạt 8480ms

        Như vậy với kết quả lần 2, nếu em coi ngưỡng của sever là lúc 15:14 đạt 34.7 hits ( lúc này time trả về lại chỉ có 6879ms)
        và độ an toàn là lúc 15:13:30 đạt 29,27 hits với time là 6953ms
        –> em đang băn khoăn về time trả về lúc ngưỡng 34,7 hits với time còn nhỏ hơn lúc time trả về lúc an toàn .
        Thế nên kết quả này là chưa ổn đúng không ạ?

        Em cảm ơn anh.

        • Sẽ rất vui nếu em chuyển những dòng chat này thành hình ảnh và text vào skype cá nhân của anh.
          Anh chưa đọc kỹ comment của em. Anh sẽ chờ tin nhắn của skype và tất nhiên, anh có thể không reply lại ngay. Mong em thông cảm!

  2. hello bạn,
    cảm ơn bạn đã chia sẻ, mình cũng hay đọc blog của bạn vì có nhiều kiến thức hay. Cho mình hỏi tại sao bạn lại cần thông số duration? tại sao bạn k dùng loop thay vì duration?

    giả sử mình có 10 CCUs và run 1 cái scenario hết 1 tiếng, nhưng duration là 30 mins thì sao? hoặc nếu duration mình set là 1h20′ thì sao? nó có loop k? Hay là nó chỉ run đúng hết scenario đó rồi dừng? Do mình cũng test performance nhưng mình hay set theo loop chứ k set duration.

    • Hi bạn, mình run theo duration chứ mình ko run theo loop vì mình muốn cố định thời gian run test, chứ không muốn run theo tổng số request.
      Về câu hỏi của bạn:
      1. mình có 10 CCUs và run 1 cái scenario hết 1 tiếng –> làm thế nào để xác định là run hết 1h, chẳng nhẽ có cách khác set time ngoài duration?
      2. nhưng duration là 30 mins thì sao? –> run 30′ rồi dừng
      3. nếu duration mình set là 1h20′ thì sao –> run đủ 1h20′ thôi
      4. nó có loop k? –> duration có nghĩa là tự loop cho đến khi hết thời gian, không quan tâm là sẽ loop bao nhiêu lần.

      • 1. mình có 10 CCUs và run 1 cái scenario hết 1 tiếng –> làm thế nào để xác định là run hết 1h, chẳng nhẽ có cách khác set time ngoài duration? -> do cái scenario đó thôi, ví dụ mình run thử 10 CCUs ra đc 30 mins, thì 20 CCUs ra 1h, ví dụ vậy thôi, còn thực tế thì mình k estimate chính xác là hết 1 giờ đc, nhưng mình dựa vào con số thực tế để tính ra time của cái test đó chạy.

        2,3,4 – Cảm ơn bạn về câu trả lời của việc loop nhé.

  3. Hi anh, em cũng đang học và tìm hiểu về peformance testing
    Anh cho em hỏi:
    Đối với một sample test cụ thể thì có công thức nào cụ thể để tính được TPS sau mỗi lần chạy không ạ?
    Ví dụ em có test chức năng login , thì TPS mình nên focus vào step Click login hay là lấy giá trị ở cột TOTAL trong Aggregate report ?
    Cách tính TPS thì như nào ạ?

    • Bạn muốn TPS thì cách tính như RPS thôi bạn, bạn thay số Request bằng Transaction là được.
      TPS = (tổng số transaction)/(tổng thời gian)
      Nhưng trong report, người ta đã tính cho hết rồi, bạn cần tự tính làm gì?
      Bài này có thể có những cái bạn cần.

  4. Em chào anh ạ, hiện em đang được assign thực hiện kiểm thử mq performance. Cụ thể là kiểm thử hiệu năng của ứng dụng phát triển xem khi mà nhận 100msgs từ IMB MQ server sau đó trả về msg thì thời gian respond là bao lâu,… anh cho em hỏi anh đã có kinh nghiệm test MQ chưa ạ?
    Nếu anh đã từng làm qua có thể chia sẻ kinh nghiệm giúp em được không ạ?
    Em cảm ơn ạ!

    • Hi bạn,
      Mình chưa có làm với MQ bao giờ nên chắc không giúp gì cho bạn được, bạn có thể lên group skype jmeter, hình như có 1 vài bạn làm cái đó rồi.

Leave a Reply

Your email address will not be published. Required fields are marked *