Hi Vtitans,
Có lần mình nhận đơn là một luồng CI/CD trong đó có khâu performance test dùng JMeter. Hai suy nghĩ (thoạt nhìn thì) trái ngược đến trong đầu mình:
"Vâng muốn tự động hoá thì được, JMeter được thiết kế command line first và lập trình được mà"
"Không, nhét performance test vào CI/CD không phải là điều bình thường mới"

Vậy là thêm một bài blog nữa đến từ team DevOps của D9, và tiêu đề của nó phản ánh một nửa nội dung. Mình sẽ giải thích vì sao có thể và điều gì không nên, hi vọng anh em DevOps tham khảo và quyết định theo tình huống nhé.

Nửa thứ nhất - Không phải là "có thể automate", mà là "phải automate"

Vâng nói hơi phũ nhưng mà thật thà, ai cũng phải mở cái giao diện GUI, tạo bài test và chạy nó, nhưng đó chỉ là bước very first để tạo ra script và hành trình làm performance test có 1000 step như thế.

Đầu tiên là chả ai test một lần.

Load test là qui trình thống kê, bạn phải đưa ra con số trung bình tin cậy và tính tin cậy này đòi hỏi bạn phải test nhiều lần. Số mẫu càng lớn thì thống kê càng tin cậy, dễ hiểu mà phải không? Sẽ rất sai nếu bạn test đúng một ngày mà mạng mẽo có vấn đề đâu đó, rồi test lại version 2 vào một ngày mạng khoẻ, và báo cáo là "dạ chúng cháu đã optimize".

Một bài test nên tuỳ biến được cho những lần test có mục đích khác nhau

Sau khi trang bị hiểu biết về hệ thống, tester sẽ viết kịch bản test thăm dò (exploratory - mình chả sính chữ nhé, chỉ là có từ search được và có từ không), dựa trên kết quả thăm dò tiếp tục lên kế hoạch, liên tục sửa đổi kịch bản test để: 1) sửa những vấn đề của chính bài test và 2) đánh giá các point khác nhau.
Capacity test đánh giá hệ thống có thể đáp ứng ở mức độ nào thì ít lỗi.
Stress test tạo ra tình huống critical (như số lượng truy cập tăng vọt) để tìm hiểu hệ thống ứng xử thế nào, các lỗi sẽ xảy ra ở đâu và không xảy ra ở đâu.
Load test được thực hiện trong điều kiện hệ thống không stress, vì mục đích là đánh giá response time và response time thì chỉ có ý nghĩa khi error rate thấp.
Long run test để phát hiện memory leak.
Test tất cả để phát hiện trade-off (optimize bằng cách đổi workload từ chỗ nọ sang chỗ kia - bài này có ông nào bí phải mưu hèn kế bẩn chưa ^^).
Test chọn lọc chỉ tập trung vào một điểm để đánh giá nhanh trước khi đánh giá toàn diện, giúp tiết kiệm chi phí. Ví dụ đang focus vào optimize function A thì hãy test A thôi đã.

Các công cụ automate đến từ chính JMeter

Điều này có nghĩa là, một script có thể tuỳ biến (truyền data và config tự động khi run) và một tester am hiểu các component của JMeter sẽ vận dụng nó để viết một lần cho rất nhiều lần chạy và mục đích test khác nhau.
Ngắn gọn thì mọi thứ trong kịch bản đều tuỳ biến được, từ số lượng user, loop / duration, endpoint, think time, ... cho đến các data loằng ngoằng trong phạm vi một request hay một thread (random, unique, real time - caculated, extracted), cho đến các logic (wait, synch, asynch, if).
Mình chỉ dùng JMeter ở mức độ beginner (thực ra cái gì mình cũng chỉ biết đến mức này, tại trái ngành mà) nên liệt kê hơi lung tung:

• RegEx Extractor : chắc phải là quan trọng nhất í, vì nó lấy được data từ response mà, nên nó giúp mình qua được cửa login form
• Cú pháp biến và biểu thức, tập function có sẵn của JMeter
• External CSV data file
• Các object, list hay map có sẵn (ctx, props, ...) : hơi khó dùng vì nắm được scope của bọn chúng thì mình không có cửa, lúc nào bí lắm mới phải lôi ra dùng và test thật cẩn thận
• Beanshell (sampler, pre- và post- processor), Groovy hay JSRxxx gì đấy để tính toán, đại khái là code Java (hoàn toàn có thể load thư viện vào nhé - nghĩa là bạn có thể làm bất cứ việc gì như xử lý full size half size Kanji hay gọi một service của AWS - khoe hộ Apache thế thôi chứ mình không trù ẻo bạn phải viết cái gì kinh thế)

Automate report

Đoạn script sau demo việc chạy một bài test và tự động gen ra report dưới dạng CSV và chart:

#!/bin/bash
# Configure where you install Jmeter and its extension
JMETER_HOME=/home/ec2-user/Apps/apache-jmeter-3.0
#JMETER_HOME=/d/Apps/apache-jmeter-3.0
export PATH=$PATH:$JMETER_HOME/bin
reporter="$JMETER_HOME/lib/ext/CMDRunner.jar"
# Name of your test script (without .jmx)
t="Test100"
# Run test, jtl file (-l) records all samplers (requests) and will be used to generate reports later
jmeter -n -t "${t}.jmx" -l "${t}.jtl" 
# Use -J parameters to pass arguments if necessary, for example:
# jmeter -n -t "${t}.jmx" -l "${t}.jtl" -Jthreads=10 -Jhost="abc.com"
# Generate Aggregate Report (CSV)
java -jar "${reporter}" --tool Reporter --input-jtl "${t}.jtl" --generate-csv AggregateReport.csv --plugin-type SynthesisReport
# Generate ResponseTimesOverTime chart (PNG)
java -jar "${reporter}" --tool Reporter --input-jtl "${t}.jtl" --generate-png ResponseTimesOverTime.png --plugin-type ResponseTimesOverTime --width 6000

Nếu bạn đã nhận ra, jtl thực ra là file CSV, bạn sẽ suy ra là có thể làm vài việc với nó như là merge kết quả của nhiều lần test, extract riêng một số request, hoặc monitor nó để phát hiện lỗi 5xx trong quá trình chạy test. Còn ext/CMDRunner.jar giúp bạn thực hiện thống kê toán học và vẽ chart, và bạn luôn có thể chạy lại report và phân tích lại chừng nào còn giữ file jtl.

Nửa thứ hai - Test Campain thay vì CI/CD?

Một lần nữa, mình là dân trái ngành, đi làm IT chỉ vì không có đôi tay to để làm lake supporter nên sẽ ngại bàn về công nghệ. Điều mình dựa vào là khi các công ty hay dự án triển khai một luồng CI/CD thì họ thực sự đang mong muốn cái gì. Nếu mục đích là "lấy feedback nhanh mỗi khi có commit hay tập commit mới", thì plug performance test vào luồng đó có vẻ không hợp lý. Có rất nhiều concern nhưng do bài viết đã dài quá, mình chỉ nêu hai đại diện thôi.

Một là, performance test ảnh hưởng mạnh đến hệ thống nên chả ai chạy nó trên production trừ các đại gia như sàn ICM (mình chơi sàn này, cháy rồi nhé hi hi), thế nhưng để test ra vấn đề, ví dụ bạn query vào bảng có nhõn nghìn bản ghi thì có ý nghĩa gì, nên phải có một đoạn build/inject dataset, và máy cũng phải to to. Hoặc phải maintain một môi trường riêng cho nó => thế thì luồng cho nó cũng riêng.
Hai là, do lead cũ của mình bảo thế. Đại khái một công ty làm product và họ tổ chức các campaign (3 tháng hoặc main release) để đo đạc tổng thể và đi trước user trong việc báo lỗi thôi, chứ không thường xuyên đến mức có commit lại deploy và chạy load test.

Kết luận: nếu lead mới bảo thì mình lại làm, lời lỗ ổng chịu mà. Gì chứ JMeter với CI/CD D9 làm cái 1 (5 xong) ^^

Thân, from Châu D9