Phiên sáng - 05 - Chia sẻ về Open Infrastructure trên thế giới
Đánh giá tải với Gatling [Meetup #21 - 02]
1. Đánh giá tải với Gatling
Người trình bày: Nguyễn Bá Thành
2. About me
● Công Ty Nhân Hòa
● github.com/lacoski
● thanh.nguyenba0611@gmail.com
3. Cấu trúc
1. Performance Testing
2. Tổng quan về Gatling
3. Ước lượng tải với Gatling
4. Distributed Gatling
5. Demo
4.
5. Performance tests - tổng quan
Kỹ thuật nhằm đánh giá hiệu năng hệ thống (Performance Testing)
Kỹ thuật kiểm thử nhằm xác định băng thông, khả năng xử lý, khả năng
mở rộng dưới một khối lượng truy cập, khối được công việc xác định -
Theo wiki
6. Performance tests - mục tiêu
Đánh giá hiệu năng, hiệu suất sản phẩm
Đánh giá hạ tầng, mô hình triển khai
Tìm ra các vấn đề ảnh hưởng tới hiệu năng sản phẩm
Hỗ trợ điều chỉnh hệ thống
7. Mô phỏng môi trường (càng giống production càng tốt):
- Hardware - Phần cứng:
- Cpu, Ram, Storage v.v
- Ảo hóa hoặc Vật lý
- Software - Phần mềm:
- OS, Proxy, LB, DB, Web Server (Version v.v)
- Data - Dữ liệu:
- Dữ liệu mẫu phục vụ tests
Performance tests - cần gì?
9. Performance tests - cần gì?
Để cải thiện hiệu năng:
1. Thu thập dữ liệu(logging, monitoring, reports)
2. Tìm điểm gây nghẽn (bottleneck)
3. Giải quyết
4. Thu thập dữ liệu và kiểm chứng sự thay đổi
5. Quay lại bước 1
10. Performance tests - vấn đề?
Hạ tầng
- Triển khai môi trường phục vụ việc đánh giá
Dữ liệu mô phỏng
- Dữ liệu phục vụ việc đánh giá
11. Performance tests - vấn đề?
Test hoặc bài tests?
- Kịch bản
- Viết và maintenance
12.
13. Gatling - Tổng quan
Công cụ kiểm tra tải thông minh, cao cấp, dễ sử dụng.
Phát triển từ ngôn ngữ Scala (tùy chỉnh, tạo bài test linh hoạt).
Hỗ trợ tốt giao thức HTTP, Hỗ trợ nhiều giao thức khác (WebSockets,
JMS, MQTT, …).
14. Tại sao dùng Gatling
- Dễ tiếp cận, sử dụng
- Report:
- Gatling cung cấp Report rõ ràng, chi tiết, dễ đọc (biểu thị dưới dạng biểu đồ).
- Continuous integration (CI):
- Gatling scripts phong phú thêm các bài test khi áp dụng CI (Jenkins plugins)
- Tạo tải tốt:
- Có thể tạo tải tối đa tới 20K user cùng một thời điểm (Từ 1 node duy nhất)
- Sử dụng ít CPU, RAM, tương thích cao với nhiều OS
15. Hiệu năng
- Tạo tải với một thread duy nhất, sử dụng ít tài nguyên
- Tool truyền thống 1 user = 1 thread => 1000 user = 1000 thread => Khi thread chờ
phản hồi, chúng sẽ đặt vào trạng thái sleep => Dùng nhiều CPU, RAM, giảm hiệu
năng test
- Sử dụng kiến trúc non-blocking, asynchronous stack (scala, akka,
netty)
- Mô hình actors
- Xử lý kịch bản dưới dạng message bất đồng bộ.
- Sử dụng akka library, netty, scala
16. Usability, Maintainability
- Hỗ trợ Proxy Recorder
- Cho phép sinh các script scala động. Không cần tự viết
- Sử dụng ngôn ngữ Scala
- Tạo ra đa dạng các bài test dựa trên ngôn ngữ lập trình Scala.
- Dễ đọc, dễ hiểu hiểu, dễ chỉnh sửa nâng cấp kịch bản
18. Cách sử dụng Gatling
- Bước 1: Tạo kịch bản (Gatling Recorder)
- Bước 2: Chạy kịch bản (Gatling Test)
- Bước 3: Phân tích report (Gatling Report)
- Vẫn cần monitor dịch vụ
- Bước 4: Đánh giá, thay đổi tải, trở lại bước 2
- Bước 5: Kết luận
19. Các tham số cần lưu ý
Phía Gatling:
- Phản hồi - Response time
- Băng thông, thông lượng - Throughput, Req/s, CCU
Phía dịch vụ:
- Tài nguyên sử dụng - Cpu, Ram, Bandwidth, Disk IO, Conn
Cám ơn mọi người đã giành thời gian lắng nghe bài trình bày
Sau đây, em sẽ trình bày chủ đề ‘Đánh giá tải với Gatling’
Giời thiệu bản thân:
Tên
Vị RD, Sản phẩm em đang tập trung phát triển là Portal dịch vụ cloud (cuối thàng release version mới có nhiều tính năng thú vị mong được các anh/chị quan tâm.
Emai, github
- Trước khi triển khai 1 hệ thống, 1 dịch vụ từ môi trường lab, môi trường test => product => yêu cầu về cái nhìn tổng quan về hiệu năng của hệ thống là vấn đề quan trọng. Vì ko có gì đảm bảo hệ thống ở môi trường lab hay môi trường test sẽ hoạt động ổn định tại môi trường production. Hay 1 sản phẩm từ môi trường dev tới môi trường thực tế rất khác nhau. Có rất nhiều vấn đề chỉ khi hệ thống có người sử dụng thực hay chạy ở mức tải cao mới xuất hiện.
- Hoặc theo case, ticket Khách Hàng Report về Nhân Hòa khi gặp vấn đề về hiệu năng.
Và vấn đề thường tập trung vào:
- Code không tối ưu
- Lựa chọn cấu hình hệ thống không đáp ứng được tải
- Tunning, sizing các cấu hình của dịch vụ chưa tốt (OS, Webserver, database, proxy).
=> Và để ước lượng được tải, để tìm ra được các vấn đề tiềm ẩn bên trong hệ thống, dịch vụ => Chúng ta cần đến kỹ thuật hoặc khái niệm Performnace testing
Mục tiêu của performace testing là ước lượng hiệu năng của hệ thống trước khi triển khai - Khả năng đáp ứng được bao lượt truy cập, độ ổn định khi hoạt động
Load testing - Mô phỏng hệ thống khi cao điểm
Stress Test - Mô phỏng hệ thống khi quá tải
Endurance testing - Mô phỏng hệ thống khi hoạt động trong 1 thời gian dài
Volume testing - Mô phỏng hệ thống khi xử lý lượng dữ liệu lớn
Đánh giá hiệu năng
- Dự đoán hoặc ước tính các đặc tính hiệu suất của sản phẩm => Đánh giá độ sẵn sàng của sản phẩm
Đánh giá cơ sở hạ tầng
- Đánh giá sự ổn định, các ngưỡng, phản hồi, hiệu suất
- Đánh giá băng thông
Tìm các vấn đề ảnh hưởng tới hiệu suất
- Thiếu RAM, CPU năng lực không đủ, tốc độ ổ đĩa …
=> Điều chỉnh hệ thống
Lưu ý: Kỹ thuật này sẽ đánh giá tải toàn bộ hệ thống, bao gồm nhiều thành phần khác nhau (web, db, lb, storage)
Cần mô phỏng phân cứng, phần mềm đặc biệt
-Dữ liệu: Hệ thống có 1 user khác với hệ có hàng nghìn user
Với nhân hòa: Khi Khách hàng sử dụng dịch vụ Nhân Hòa (Cloud), khi có vấn đề hiệu năng reports => Clone hệ thống lên cloud của Nhân Hòa => Benchmarks trên hệ thống clone ko làm gián đoạn dịch vụ.
Dữ liệu chính là yêu tố cốt lõi khi thực hiện Performance test
Dữ liệu đến từ đâu: ?
Nếu ko có dữ liệu => ko thể ước lượng, kết luận hiệu năng hệ thống Performance tests
Mục tiêu cuối: Tìm ra hiệu năng cuối hoặc điểm gây nghẽn
Hạ tầng triển khai đánh giá dịch vụ:
Thông thường nghiên cứu hệ thống => Triển khai trên môi trường lab => Rất khó đánh giá hiệu năng
Sản phẩm của nhóm phát triển (Nhóm dev) thường chỉ chạy trên môi trường lab nhỏ, hoặc máy tính cá nhân => Triển khai thực tế ko bảo đám hiệu năng
Vấn đề chi phí => Không thể lúc nào cũng sẵn sàng phần cứng hạ tầng test.
Dữ liệu mô phỏng
Hệ thống có 10 - 100 user khác hệ thống có hàng nghìn user, phải có dữ liệu thật mới có thể đánh giá hiệu năng
=> Với Nhân hòa, khi khách hàng yêu cầu kiểm tra hiệu năng => Migrate dịch vụ họ lên hạ tầng cloud nhân hòa => Benchmark, performace với hạ tầng cloud sẵn có ko gián đoạn dịch vụ khách hàng
Thiết kế kịch bản (mô phỏng người dùng thực vào hệ thống)
Việc viết test và bảo trì các bài test
Thời gian, nhân lực, chi phí bỏ ra.
Có nhiều công cụ hỗ trợ tại tải test thì tại sao em lại lựa chọn Gatling?
Tiêu chí đánh giá công cụ:
Đơn giản sử dụng, không phải trả phí
Hiệu năng tốt
Mã nguồn mở, Dễ tích hợp
Thân thiện với developer.
Gatling đáp ứng tiêu chí trên
Gatling cung cấp Report rõ ràng, chi tiết, dễ đọc được biểu thị dưới dạng biểu đồ. Ngoài ra, Gatling còn cho phép tích hợp Report với một số phần thứ 3 như Graphite, influxdb, v.v. Ngoài ra, Gatling còn cho phép tích hợp Report với một số phần thứ 3 như Graphite, influxdb, v.v.
Blocking IO là có nghĩa là xử lý đơn luồng. Thông thường một thao tác máy tính chỉ xảy ra khi các thao tác trước đó đã hoàn thành. Một ví dụ điểm hình cho Blocking IO là xử lý hàng đợi, mỗi phần tử khi thêm vào hàng đợi sẽ phải chờ các phần tử trước nó đã thêm thành công thì nó mới được thêm.
Viết bằng scala, scala là ngôn ngữ phát triển từ java => Kế thừa được các thư viện tốt nhất.
akka library, netty là các thư viện async nổi tiếng của ngôn ngữ java
Mô hình Actor
Actor có "mailbox"
Cơ chế bất động bộ, giả sử gửi 3 tin nhắn tới actor, cả 3 tin nhắn được xử lý đồng thời. Nhưng để xử lý các tin nhắn chúng ta cần khái niệm mailbox. Đơn giản mailbox nhận cả 3 tin nhắn đồng thời nhưng thực hiện từng tin nhắn một => Chính là lý do Gatling có thể tạo ra tải lớn trong một thời điểm.
Actor có thể thực hiện (process, communicate, storage)
Tạo ra nhiều actor khác
Gửi message tới actor khác
Phản hổi đối với tin nhắn nhận được
Actor giống với user được giải lập, mailbox tức địa chỉ gửi nhận các message hay request người dùng
Jenkins là một phần mềm tự động hóa, mã nguồn mở và viết bằng Java. (CI - tự động lấy code về, tự động build, tự động báo lỗi, tự động deploy.)
Tham số cơ bản khi thực hiện performance test với gatling.
Trong trường hợp:
- Chạy gatling từ xa (remote)
- Chạy gatling theo cụm (Sử dụng cluster để tạo mức tải cao)
Trong trường hợp:
- Chạy gatling từ xa (remote)
- Chạy gatling theo cụm (Sử dụng cluster để tạo mức tải cao)
Trong trường hợp:
- Chạy gatling từ xa (remote)
- Chạy gatling theo cụm (Sử dụng cluster để tạo mức tải cao)
Trong trường hợp:
- Chạy gatling từ xa (remote)
- Chạy gatling theo cụm (Sử dụng cluster để tạo mức tải cao)
Trong trường hợp:
- Chạy gatling từ xa (remote)
- Chạy gatling theo cụm (Sử dụng cluster để tạo mức tải cao)
Tạo Apache, bench băng abtool và gatling để thấy sự khác biệt (CPU tại máy client, tải trên node được test)
Bước 1:
- Hướng dẫn sử dụng gatling đơn giản (quay)
- Cần chuẩn bị script được viết lại bằng scala
Bước 2:
- Chạy kịch bản với scala vừa dùng
- Chạy với kịch bản scala đã tốt ưu
Bước 3:
- Đánh giá Site wordpress = report
- Đưa tham số giám sát trên Server
=> Đưa ra kết luận