Disclaimer:

Tất cả là suy nghĩ của mình, chưa tham khảo các performance tester chuyên nghiệp. Nên không chắc được là những thứ dưới đây có đúng không.

Mình quan sát thấy phần đông các tester đều 1 vài lần được yêu cầu làm test hiệu năng của hệ thống, của trang web. Với những lần như vậy, các bạn vừa lo vừa vui. Các bạn lo vì chưa làm bao giờ, chưa biết bắt đầu từ đâu, dùng tool gì, làm thế nào… Vui vì được làm cái mới, tạm xa rời những công việc manual vẫn làm. Và trong mỗi bạn lại nhen nhóm cái ý tưởng, học đến nơi đến chốn luôn, nhưng rồi lại chẳng đi đến đâu vì lớp học performance hiếm và tools có vẻ khó hiểu hơn so với tưởng tượng.

Vậy nếu mình học performance đến nơi đến chốn thì mình sẽ học cái gì?

I. Đầu tiên, đọc lại định nghĩa performance test

Performance test là 1 kiểu test non-functional, nó có thể được dùng để test 1 phần hệ thống hoặc toàn bộ hệ thống. Nó chính là cái cấu thành nên cái gọi là “Scalability – khả năng mở rộng”, 1 trong 3 tính chất quan trọng của 1 hệ thống, bên cạnh Reliable và Mantainable. [Chương 1, sách Designing Data-Intensive Application – Martin Kleppmann]

Đối với 1 hệ thống bất kỳ, những con số kết quả từ performance test nó trả lời cho 2 câu hỏi:

• Khi tăng lượng load và giữ nguyên tài nguyên hệ thống (CPU, memory, bandwidth…), với 1 scenario cụ thể, thì hệ thống sẽ bị ảnh hưởng như thế nào?
• Khi tăng lượng load, cần phải tăng tài nguyên hệ thống lên bao nhiêu để giữ hiệu năng không đổi?

Vậy con số nào là con số mà ta sẽ phải quan tâm:

• Throughput: số lượng X mà hệ thống có thể handle được trong 1 khoảng thời gian
• Response time: tổng thời gian mà 1 X được xử lý.

“X” ở trên là cái gì vậy? Nó có thể là HTTP request, tỉ lệ reads/writes của 1 database, number users trong room chat, hit rate của cache…

II. Hiểu thật rõ hệ thống mà mình test?

• Hệ thống đó là hệ thống gì? Web Application, Log Handler, Text search, Web RTC …
• Đọc về kiến trúc hệ thống, nếu có bản vẽ là dễ nhất –> phải biết được chức năng của mỗi thành phần và cách hoạt động của mỗi thành phần đó, input, output. Ví dụ như mình làm việc với Web App, mình sẽ phải hiểu về web server, load balancing, database, cache…
• Đọc kỹ về cái protocol mà mình sẽ thực hiện test, cơ chế, thành phần yêu cầu. Ví dụ như HTTP, HTTPS, web socket, TCP…

III. Tạo các kịch bản test và metrics đánh giá cần thiết

Sau khi hiểu rõ về technical rồi, mình sẽ suy nghĩ về các kịch bản mà mình sẽ sử dụng, kịch bản cho mỗi hệ thống sẽ khác nhau.

Và ta sẽ phải xây dựng những metrics tương ứng cho hệ thống, sẽ phải monitor những thông số gì, ý nghĩa của từng con số và thông số ấy được tính trên công thức gì. Nếu càng rõ phần metrics thì phần đọc kết quả test càng dễ.

IV. Cách xây dựng test script

Wow, test script là phần các bạn hay phi vào đầu tiên, nhưng với mình thì lại đứng ở vị trí thứ 4. Vì sao? Cách học của mình hơi cổ tí, thay vì thực hành trước, tìm hiểu lý thuyết sau, mình hay dành rất nhiều thời gian để học lý thuyết, sau đó mới thực hành.

Đây cũng là phần quan trọng, vì build test script sai thì đừng hi vọng có kết luận đúng. =)))

Điều kiện đầu vào của phần này là

• Thật hiểu hệ thống
• Hiểu scenario mà mình đang phải làm

Ngoài ra, có 1 thứ vô cùng quan trọng đó là cách sử dụng tools

• Tool đó có support được cái bạn định test không? HTTP, TCP, LDAP …
• Tool đó được viết bằng ngôn ngữ gì? tool GUI hay code? Cơ chế hoạt động của tool
• Làm thế nào để config lượng load? lượng load đó được sinh ra như thế nào?
• Các thành phần xử lý những bài toán nhỏ hơn: variable, extract value, code snippet…
• Có hỗ trợ debug ko?
• Output có định dạng gì? file, database…Output đó có dễ thể hiện trên các visual tool không?

V. Cách đọc kết quả test

Thông thường, quá trình test xảy ra trong 1 giai đoạn thời gian, có thể là 30min, 1h, 2h. Kết quả của test là các thông số sẽ được sắp xếp theo thứ tự thời gian. Sau đó từ cái bảng kết quả theo kiểu time-series data đó, mình sẽ có được kết quả dưới dạng các thông số của thống kê, như min, max, mean, median, percentile… Càng hiểu ý nghĩa của các con số thống kê, mình càng hiểu kết quả và đưa ra kết luận chính xác. Đây cũng có lẽ là nguyên nhân chính mà các bạn tester thường rất bối rối không biết phải đọc kết quả như thế nào.

Ví dụ, average của response time cho request A là 3s, ta nghĩ là response time trung bình là 3s, nhưng ta không nên đưa 3s làm con số report. Vì sao? Vì ta cần nhìn vào toàn quá trình run test, có 4/5 requests là 500ms, và 1 request run dài 13s. Nó khác hoàn toàn với 5/5 requests có average xấp xỉ 3s.

Có lẽ phải mở lại sách thống kê hồi đại học để đọc lại 1 chút. hehe.

Ngoài ra, mình cũng phải nhìn xem system resources trong các thời điểm quan trọng để biết rằng kết quả của test là hợp lý. Ví dụ, máy server bị chạy 1 process nào đó không liên quan đến App chiếm hết memory –> server xử lý request cực tệ, không thể kết luận là performance của App là tệ được.

Hết rồi. Mình mới chỉ nghĩ đến như vậy, có lẽ sẽ rất cần đóng góp của mọi người. Thanks.