Thử nghiệm và tối ưu hóa hiệu suất chuỗi khối - Phần 1

特邀专栏作者

2023-04-02 02:04

Bài viết này có khoảng 2849 từ, đọc toàn bộ bài viết mất khoảng 5 phút

Mục đích của bài viết này là giới thiệu toàn bộ quy trình dự án hiệu suất thông qua một ví dụ cụ thể (cosmos-sdk SimApp).

tiêu đề cấp đầu tiên

đề cương

Mục đích của bài viết này là giới thiệu quy trình dự án hiệu suất hoàn chỉnh thông qua một ví dụ cụ thể (cosmos-sdk SimApp), nội dung cụ thể giới thiệu bài kiểm tra hiệu suất blockchain được sử dụng:
1. Các khái niệm cơ bản
2. Dụng cụ thông dụng

tiêu đề cấp đầu tiên

Khái niệm cơ bản

Thử nghiệm hiệu suất chuỗi khối về mặt phương pháp không khác gì thử nghiệm hiệu suất truyền thống. Có rất nhiều khái niệm khó hiểu trong kiểm thử hiệu suất, sau đây tôi liệt kê các khái niệm được mô tả trong bài viết này để làm cho một số định nghĩa.

tiêu đề phụ

Định nghĩa về kiểm thử hiệu năng

Kiểm tra hiệu suất là thiết lập các chiến lược giám sát cho các chỉ số hiệu suất của hệ thống hoặc dịch vụ, thực hiện các bài kiểm tra trong các tình huống cụ thể, phân tích và đánh giá các tắc nghẽn hiệu suất và tối ưu hóa chúng, cuối cùng thu được kết quả hiệu suất để đánh giá xem các chỉ số hiệu suất của hệ thống hoặc dịch vụ có đáp ứng các giá trị định trước hay không. Ở đây nó được giải thích cùng với chuỗi khối simapp của cosmos-sdk.
1. Cần làm rõ các chỉ báo, trong đó nói chung là hai loại chỉ báo: chỉ báo kỹ thuật và chỉ báo kinh doanh. Các chỉ số kỹ thuật nói chung là TPS, thời gian phản hồi và sử dụng tài nguyên, tương ứng với chuỗi khối, nó thường đề cập đến bao nhiêu giao dịch có thể được xử lý mỗi giây? Thời gian phản hồi hoặc số liệu thống kê cho các giao dịch này là gì? Trạng thái của các tài nguyên được sử dụng bởi hệ thống trong trường hợp này là gì? Các chỉ số kinh doanh dự kiến sẽ được đáp ứng phải đến từ số liệu thống kê của môi trường sản xuất. Lấy ứng dụng sản xuất cosmos-hub của cosmos-sdk làm ví dụ, thời gian tạo khối hiện tại là khoảng 6 giây và số lượng giao dịch trong mỗi khối hầu hết là nhỏ hơn 10. Sẽ hợp lý hơn nếu đặt chỉ số kinh doanh kỳ vọng là TPS là 100. (TPS thấp như vậy thực sự có liên quan đến các mục tiêu của cosmos-hub, vì trọng tâm chính của nó là khả năng tương tác chuỗi).
2. Mô hình thử nghiệm: Đó là sự trừu tượng hóa bối cảnh thực tế, mô tả mô hình kinh doanh trông như thế nào. Lấy cosmos-hub làm ví dụ, các nút chuỗi khối được phân phối trên toàn thế giới xử lý các giao dịch khi có khoảng 500 nút trình xác thực và khoảng 200 nút trình xác thực đang hoạt động. Tình hình thực tế có thể được trừu tượng hóa để mở rộng quy mô khi thử nghiệm.
3. Kế hoạch kiểm thử: bao gồm môi trường kiểm thử, dữ liệu kiểm thử, mô hình kiểm thử, chỉ số hiệu suất, v.v. Thử nghiệm so sánh hệ thống chuỗi khối là xác định cấu trúc thử nghiệm và chuẩn bị nội dung, chẳng hạn như 1000 người dùng và số dư của mỗi người dùng là 1000 cổ phần.
4. Cần giám sát: Các đối tượng giám sát bao gồm máy ép, nút chuỗi khối và các đối tượng khác như máy chủ cân bằng tải. Giám sát trong kỷ nguyên dựa trên đám mây nói chung là Kubernetes+Prometheus+Grafana.
5. Điều kiện kiểm thử bắt buộc: môi trường phần cứng, chiến lược thực hiện kiểm thử, v.v. Ví dụ: 4 C 8 G thì trong 60 giây đầu mỗi giây cộng thêm 10 đề.
7. Có báo cáo kết quả: Nội dung báo cáo đương nhiên là số liệu chỉ tiêu thực tế.

tiêu đề phụ

Phân loại các kịch bản hiệu suất
1. Kịch bản hiệu suất cơ sở: thực hiện các giao dịch/dung lượng đơn lẻ (lượng lưu lượng truy cập) của giao diện và chuẩn bị cho dung lượng hỗn hợp.
2. Kịch bản hiệu suất dung lượng (hỗn hợp): Thử nghiệm dung lượng hỗn hợp là do bối cảnh trực tuyến thực bao gồm các dịch vụ khác nhau, do đó, các thử nghiệm áp suất độ dốc do các dịch vụ này khởi xướng theo các tỷ lệ đồng thời khác nhau là các kịch bản thử nghiệm dung lượng hỗn hợp.
4. Kịch bản hiệu suất bất thường: Dưới áp lực mạnh, mô phỏng sự bất thường.

tiêu đề phụ

các chỉ số hiệu suất quan trọng

1. RT, Response Time
2. HPS, Hits Per Second
3. TPS, Transactions Per Second,Có nhiều chỉ số để kiểm tra hiệu suất, chẳng hạn như:
4. QPS, Queries Per Second
5. PV, Page View
6. Throughput
7. IOPS, Input/Output Operations Per Second

Giao dịch ở đây thường được gọi là "giao dịch" trong các ứng dụng truyền thống và "giao dịch" trong lĩnh vực chuỗi khối

Các chỉ số quan trọng hơn là sử dụng tài nguyên, thông lượng và thời gian phản hồi.Các nhà cung cấp dịch vụ quan tâm nhiều hơn đến hai yếu tố đầu tiên và người dùng cập nhật yếu tố sau. Tình hình chung của các chỉ số này được minh họa bằng cách tham khảo các sơ đồ cổ điển trong Phương pháp kiểm tra hiệu suất (http://hosteddocs.ittoolbox.com/questnolg 22106 java.pdf) và tình hình thực tế có thể khác. 3 dòng, 3 khu vực và 3 trạng thái được xác định trong hình, hình này đáng xem hơn và bạn có thể hiểu sơ bộ về mối quan hệ giữa các chỉ số.
1. 3 dây: Sử dụng, Thông lượng, Thời gian đáp ứng
tiêu đề phụ

hình ảnh

khác

khác
1. Nói chung, khi nào cần thực hiện kiểm tra hiệu năng.
a.Trước khi đưa dự án lên mạng, hãy ước tính khả năng chịu tải của hệ thống
b) Sau khi tái cấu trúc dự án, đánh giá hiệu quả
2. Chấm dứt một dự án nếu dự án nhận được báo cáo hiệu suất, vì vậy đó chỉ là xác minh hiệu suất. Thực hiện kiểm tra hiệu suất toàn diện và đồng thời điều chỉnh hệ thống về trạng thái tối ưu là một dự án hiệu suất hoàn chỉnh. Điều chỉnh hiệu suất mất nhiều thời gian và có thể yêu cầu sự tham gia phát triển, điều này rất tốn kém.

Thử nghiệm hiệu suất chuỗi khốiWhy blockchain performance is hard to measuretiêu đề phụ

Trì hoãn

Thời điểm bắt đầu và kết thúc của khoảng thời gian trì hoãn này được xác định như thế nào?
1. Điểm bắt đầu là người dùng nhấp vào gửi hoặc giao dịch đến mempool?
2. Điểm cuối là giao dịch được xác nhận bởi khối đầu tiên? Hay nó được xác nhận bởi khối thứ 6 (POW blockchain nghĩ vậy)? Hay là khi người dùng cuối nhận được phản hồi từ giao diện?
3. Một số hệ thống chuỗi khối đợi một độ trễ nhất định và một số lượng giao dịch nhất định trước khi bắt đầu xử lý chúng. Theo cách này, giao dịch may mắn nhất là giao dịch cuối cùng tham gia và độ trễ xử lý của nó là ngắn nhất.
5. Việc xử lý giao dịch của một số hệ thống chuỗi khối được ưu tiên, các giao dịch có phí cao được xác nhận nhanh chóng, trong khi các giao dịch có phí thấp tương đối chậm. Sự khác biệt về phí có tác động đến độ trễ giao dịch và thống kê TPS.

tiêu đề phụ

thông lượng

Một vấn đề thực tế khác là người dùng không thực sự quan tâm đến TPS của blockchain mà chỉ quan tâm đến cách sử dụng ít phí và hoàn thành giao dịch càng sớm càng tốt. Từ quan điểm này, TPS chỉ có ý nghĩa đối với các nhà cung cấp dịch vụ hệ thống.

Công cụ cơ bản

tiêu đề phụ

công cụ áp lựcJmeterDụng cụ áp lực dùng chung

Hoặc cụ thể các công cụ kiểm tra ứng dụng cụ thể như sau:

Việc sử dụng Jmeter sẽ gần với kịch bản sử dụng hơn và tổng quát hơn. Nói chung, có nhiều cách để tương tác với các nút blockchain (tương tác dòng lệnh chung cuối cùng là gọi một trong các giao diện sau)
1. giao thức gRPC

Trình lấy mẫu được hỗ trợ bởi Jmeter hỗ trợ HTTP và hỗ trợ cho giao thức gRPC cần có sự trợ giúp của trình cắmjmeter-grpc-request

tiêu đề phụ

công cụ giám sátPrometheusCông cụ giám sát chunghttps://prometheus.io/assets/architecture.pngCông cụ này có thể giám sát rất nhiều nội dung và hệ sinh thái của nó được thể hiện trong hình (

). Trong thực tế thử nghiệm các ứng dụng chuỗi khối, docker-compose thường được sử dụng để triển khai nhiều nút chuỗi khối để mô phỏng môi trường thử nghiệm chính thức, bởi vì môi trường thử nghiệm chính thức thường có cấu hình phần cứng cao, nếu không phải là phòng máy tính tự xây dựng thì hãy sử dụng đám mây Máy móc của các nhà sản xuất dịch vụ đắt tiền và điều này có thể tiết kiệm chi phí.cadvisor。

Trong docker-compose, bạn có thể giới hạn các tài nguyên được sử dụng bởi các bộ chứa, chẳng hạn như bộ nhớ và sức mạnh tính toán của CPU, thậm chí liên kết các lõi CPU. Có thể sử dụng việc giám sát các tài nguyên nàystress-nghình ảnh

hình ảnh

tiêu đề cấp đầu tiên

điều chỉnh hiệu suất

Nói chung, các siêu nguyên nhân phổ biến gây tắc nghẽn hiệu suất (tôi gọi chúng là nguyên nhân đằng sau các nguyên nhân, thường là ở cấp độ phần cứng) là mạng, CPU và ổ đĩa IO. Các hoạt động gây tắc nghẽn đĩa IO bao gồm ghi nhật ký thường xuyên, in nhật ký không cần thiết và truy cập đĩa qua mạng. Các tài nguyên này sẽ được hoàn thành thông qua các cuộc gọi hệ thống. Để theo dõi các cuộc gọi hệ thống, bạn có thể sử dụng strace để xem các cuộc gọi hệ thống nào được thực thi và thời gian dành cho các cuộc gọi này.

Một vấn đề khác có thể gặp phải là tính không ổn định của hệ thống, có thể tự biểu hiện dưới dạng sử dụng CPU/không ổn định TPS.

Nếu mức sử dụng CPU không ổn định (xu hướng ổn định, nhưng dao động lớn), từ góc độ thực thi lệnh CPU, điều đó có nghĩa là CPU ở trạng thái không hoạt động trong các khoảng thời gian khác nhau. Lý do trong trường hợp này không phải là có CPU nhàn rỗi mà là khoảng thời gian nhàn rỗi dài hay ngắn. Bạn cần sử dụng các công cụ hệ thống Linux và các công cụ lược tả tương ứng với chương trình để quan sát và tìm ra nguyên nhân.

tiêu đề phụ

công cụ phân tíchhttps://www.brendangregg.com/Perf/linux_perf_tools_full.pnghình ảnh

hình ảnh

tiêu đề phụ

Đĩa IO thường dẫn đến tắc nghẽn hệ thống và ngăn xếp đĩa IO tương đối dài nên khó phân tích. Sự quen thuộc với ngăn xếp IO sẽ giúp chúng tôi tìm ra sự cố (https://www.thomas-krenn.com/en/wikiEN/images/c/c 2/Linux-storage-stack-diagram_v 6.2.pdf)

hình ảnh