Tóm lại
- Chúng tôi đánh giá ba thiết kế BAL — BAL đầy đủ, BAL I/O theo lô và BAL I/O song song—với các sự đánh đổi khác nhau giữa Xuất lượng thực thi và kích thước BAL .
- Chúng tôi xem xét mức độ gần đạt được Xuất lượng thiết kế có chi phí vận hành thấp nhất, BAL I/O song song, so với BAL đầy đủ.
- BAL I/O song song đạt được khoảng 10,8 GGas/s so với khoảng 13,9 GGas/s của BAL đầy đủ, cung cấp 78% Xuất lượng với chỉ 33% kích thước của BAL đầy đủ.
Danh sách truy cập cấp khối ( BAL ) cho phép xử lý song song, bao gồm cả I/O song song và thực thi song song, bằng cách mã hóa rõ ràng tất cả các tài khoản và bộ nhớ được truy cập trong quá trình thực thi Block vào Block Space, cùng với các giá trị sau khi thực thi của chúng. Trong bài viết trước , chúng tôi đã nghiên cứu hiệu suất thực thi song song của BAL đầy đủ, bao gồm cả sự khác biệt về trạng thái sau giao dịch và các khóa và giá trị đọc trước khối. Trên một máy tính 16 lõi thông thường, chúng tôi đã đạt được Xuất lượng thực thi song song thuần túy khoảng 15 GGas/s trong thiết lập mega-block.
Tuy nhiên, nghiên cứu này bỏ qua hai ràng buộc quan trọng: I/O và chi phí BAL lớn. Trong kịch bản không khởi động trước, I/O chiếm khoảng 70% tổng thời gian xử lý Block . Mặc dù BAL cho phép đọc đĩa song song, hiệu quả của I/O song song được hỗ trợ bởi BAL có thể phụ thuộc vào lượng thông tin đọc được nhúng trong chính BAL . Các gợi ý đọc chi tiết hơn có thể tăng tính song song của I/O, nhưng chúng cũng làm tăng kích thước BAL , ảnh hưởng trực tiếp đến băng thông mạng và chi phí lưu trữ. Do đó, BAL có một số biến thể thiết kế, mỗi biến thể thể hiện một sự đánh đổi khác nhau giữa tính song song có thể đạt được và kích thước BAL . Dựa trên độ chính xác của các gợi ý đọc, các thiết kế chính là: BAL đầy đủ, BAL I/O theo lô và BAL I/O song song.
| Tên | Chi tiết | Thực thi song song | Đầu vào/đầu ra song song | Kích thước BAL (được mã hóa RLP)* |
|---|---|---|---|---|
| BAL đầy đủ | Sự khác biệt về trạng thái sau giao dịch và các khóa và giá trị đọc trước khi chặn | Mỗi giao dịch | Gợi ý từng bước (chỉ để xác minh) | 213 kb |
| Batch I/O BAL | Sự khác biệt về trạng thái sau giao dịch và các khóa đọc trước khi chặn. | Mỗi giao dịch | Gợi ý mỗi lần | 110 kb |
| BAL đầu vào/đầu ra BAL | Sự khác biệt về trạng thái sau giao dịch | Mỗi giao dịch | Mỗi giao dịch | 71 kb (thấp nhất, 33% của Full BAL, 64% của Batch I/O BAL) |
*Lấy mẫu từ các khối # 23.770.000–23.771.999
Lý tưởng nhất, chúng ta muốn tối đa hóa Xuất lượng trong khi giảm thiểu kích thước BAL . Mặc dù BAL đầy đủ mang lại hiệu suất cao nhất, nhưng nó cũng gây ra chi phí vận hành lớn nhất. Điều này đặt ra một câu hỏi quan trọng: thiết kế có chi phí vận hành thấp nhất — BAL I/O song song — có thể đạt được Xuất lượng đương với BAL đầy đủ đến mức nào? Giải quyết câu hỏi này là mục tiêu chính của nghiên cứu này.
Để trả lời câu hỏi đó, chúng tôi đã xây dựng một môi trường thực thi bao gồm việc tải trạng thái thông qua các thao tác đọc I/O, với thiết lập như sau:
- Một cơ sở dữ liệu phẳng dùng cho tài khoản, lưu trữ và mã hợp đồng, như được sử dụng trong Reth.
- Các bên gửi giao dịch đã được khôi phục trước, tận dụng khả năng song song hóa quá trình khôi phục bên gửi đã được triển khai trong hầu hết các ứng dụng khách.
- Việc bỏ qua quá trình tính toán gốc trạng thái và cam kết cây trie trạng thái, vốn có chi phí có thể được phân bổ cho các khối lớn và không phải là trọng tâm của nghiên cứu này.
Sử dụng cấu hình này, chúng tôi đã đánh giá hiệu năng thực thi song song trên mỗi giao dịch (bao gồm I/O song song và thực thi song song) với các thiết kế BAL khác nhau. Kết quả cho thấy BAL I/O song song vẫn đạt được khoảng 10,8 GGas/s trên một máy tính 16 lõi thông thường ở chế độ mega-block, tương đương với khoảng 13,9 GGas/s khi sử dụng BAL đầy đủ. Điều này chứng tỏ rằng, so với BAL đầy đủ, BAL I/O song song đạt được 78% Xuất lượng của BAL đầy đủ chỉ với 33% kích thước BAL , mang lại sự cân bằng hợp lý giữa Xuất lượng và chi phí kích thước BAL .
Nút thắt cổ chai I/O trong quá trình thực thi Ethereum
Ethereum đang tiếp tục mở rộng quy mô L1. Bản nâng cấp Fusaka đã tăng Gas Limit từ 45 triệu lên 60 triệu, và Glamsterdam dự kiến sẽ còn nâng cao hơn nữa. Nghiên cứu trước đây của chúng tôi cho thấy BAL có thể cải thiện Xuất lượng thực thi lên một bậc, tạo nền tảng vững chắc cho giới hạn gas cao hơn.
Bất chấp những cải tiến này, I/O vẫn là một nút thắt cổ chai lớn trong quy trình xử lý Block hiện nay. Trong thiết lập không có khởi động trước, I/O chiếm khoảng 70% tổng thời gian thực thi. Lấy Reth làm ví dụ:
- Việc thực thi đơn luồng với I/O (sử dụng MDBX) chỉ đạt được khoảng ~350 MGas/s.
- Nhờ quá trình làm nóng trước, chi phí I/O giảm xuống còn khoảng 20%, và Xuất lượng được cải thiện lên khoảng 700 MGas/s.
Mặc dù việc làm nóng trước có ích, nhưng vẫn còn nhiều dư địa để khai thác. Giới hạn cơ bản đối với I/O nằm ở các kiểu truy cập I/O tuần tự. Mặc dù các ổ SSD NVMe hiện đại hỗ trợ hàng đợi I/O sâu (thường lên đến 64), hầu hết các máy khách Ethereum vẫn thực hiện đọc trạng thái tuần tự và không tận dụng hết khả năng song song hóa I/O hiện có.
BAL giải quyết hạn chế này bằng cách cho phép I/O song song, nhưng điều đó phải trả giá. Sự khác biệt về trạng thái sau giao dịch là rất cần thiết cho việc thực thi song song — nghiên cứu trước đây của chúng tôi đã chỉ ra rằng chúng cho phép tăng tốc gấp 10 lần so với thực thi tuần tự. Tuy nhiên, các giá trị đọc và gợi ý đọc có thể có kích thước tương đương với sự khác biệt về trạng thái , trong khi lợi ích về hiệu suất mà chúng mang lại so với chi phí mạng và lưu trữ bổ sung này lại không rõ ràng.
Điều này đặt ra một câu hỏi thiết kế quan trọng: nếu có thể đạt được hiệu suất gần tối ưu mà không cần bao gồm các giá trị đọc—hoặc thậm chí cả các gợi ý đọc—thì kích thước BAL có thể giảm đáng kể, làm giảm chi phí mạng và lưu trữ mà không làm giảm Xuất lượng. Để kiểm tra giả thuyết này, chúng tôi tập trung vào BAL I/O song song, chỉ bao gồm sự khác biệt trạng thái sau giao dịch và thực hiện đọc trạng thái theo yêu cầu trong quá trình thực thi.
Phương pháp thực nghiệm
Để đánh giá giới hạn hiệu năng tối đa mà I/O song song BAL mang lại, chúng tôi đã xây dựng một môi trường thực thi đơn giản bằng cách loại bỏ các thành phần không liên quan đã đề cập ở trên. Điều này cho phép chúng tôi đo lường giới hạn trên thực sự của khả năng song song hóa được hỗ trợ bởi BAL.
Tận dụng công cụ thực thi hiệu năng cao của reth và khả năng đọc đa luồng của RocksDB, chúng tôi đã sửa đổi máy khách reth để Xả các phụ thuộc thực thi (bao gồm các khối, BAL và 256 mã băm Block gần nhất), sử dụng REVM làm công cụ thực thi Máy ảo Ethereum (EVM) và giới thiệu nhà cung cấp trạng thái dựa trên RocksDB để truy cập tài khoản, mã và bộ nhớ.
Đơn giản hóa việc mô phỏng thực thi I/O
- Tất cả các giao dịch đều được thực hiện với thông tin người gửi đã được khôi phục (quá trình khôi phục người gửi có thể được thực hiện song song hoàn toàn từ trước).
- Không có thao tác tính toán gốc trạng thái hoặc cam kết cây trie nào được thực hiện sau khi thực thi (chỉ có cam kết trạng thái phẳng), vì các chi phí này không liên quan đến trọng tâm của nghiên cứu này.
Công tác kỹ thuật và thiết lập
- Đã sửa đổi máy khách Reth để hỗ trợ việc xuất toàn bộ các phụ thuộc thực thi, bao gồm các khối, BAL và 256 mã băm Block cuối cùng.
- Đã thêm trình cung cấp trạng thái rocksdb cho Revm để tải trạng thái tài khoản, mã và lưu trữ.
- Ban đầu, giao diện MDBX của Reth được thử nghiệm nhưng cho thấy hiệu suất giảm sút khi xử lý đa luồng; thay vào đó, RocksDB được lựa chọn, cùng với một công cụ chuyển đổi để chuyển đổi cơ sở dữ liệu MDBX sang RocksDB.
- Đối với I/O song song, một lớp bộ nhớ đệm dùng chung được sử dụng để tránh việc đọc dữ liệu dư thừa giữa các giao dịch.
- Xóa bộ nhớ đệm trang trước mỗi thí nghiệm.
- Độ chi tiết song song = theo từng giao dịch
- Phần cứng:
- Bộ xử lý AMD Ryzen 9 5950X (16 lõi vật lý, hoặc 32 lõi với công nghệ siêu phân luồng)
- RAM 128 GB
- Ổ SSD NVMe RAID-0 7TB (~960k IOPS đọc ngẫu nhiên cho khối 4k, băng thông 3.7GB/giây)
- Tập dữ liệu: 2000 khối mạng chính ( #23770000 –23771999).
- Chỉ số: Gas thụ mỗi giây = tổng lượng gas đã sử dụng / thời gian thực thi bao gồm cả thời gian I/O.
Bộ công cụ so sánh hiệu năng có sẵn tại đây: 
GitHub - dajuguan/evm-benchmark
Kết quả
Chúng tôi đã đánh giá các khối mạng chính Ethereum dưới chế độ I/O song song và thực thi song song với số lượng luồng khác nhau khi sử dụng BAL I/O song song. Kết quả cho thấy rõ ràng một đường dẫn quan trọng bị chi phối bởi các giao dịch chạy lâu nhất . Để giảm thiểu điều này, chúng tôi đã mô phỏng giới hạn gas Block lớn hơn, giúp mở khóa khả năng song song hóa đáng kể khi sử dụng BAL.
Với 16 Threads và Block 1G-gas, BAL I/O song song đạt được Xuất lượng khoảng 10,8 GGas/giây , gần bằng 78% so với mức ~13,8 GGas/giây đạt được bởi BAL đầy đủ . Điều quan trọng là, hiệu suất này đạt được với kích thước BAL trung bình chỉ khoảng 71 KB, giảm khoảng 67% so với BAL đầy đủ .
Phân tích đường g critical trong I/O song song và thực thi song song
Để đánh giá cả tốc độ tăng hiệu suất thực tế và ảnh hưởng của định luật Amdahl đến tính song song ở cấp độ giao dịch, chúng tôi đã tiến hành các thí nghiệm thực thi song song trên từng giao dịch để định lượng tác động của các giao dịch chạy lâu nhất đến tốc độ tăng hiệu suất có thể đạt được.
Kết quả chi tiết được hiển thị bên dưới (trong đó “độ trễ giao dịch dài nhất” là tổng thời gian thực thi bao gồm thời gian I/O của các giao dịch chạy lâu nhất trong mỗi Block):
| Threads | Xuất lượng (mg gas/giây) | Độ trễ TX dài nhất | Tổng thời gian |
|---|---|---|---|
| 1 | 740 | 6,85 giây | 60,62 giây |
| 2 | 1.447 | 6,75 giây | 31:00 |
| 4 | 2.167 | 8,11 giây | 20,70 giây |
| 8 | 2.994 | 9,02 giây | 14,98 giây |
| 16 | 3.220 | 8,92 giây | 13,93 giây |
| 32 | 3.253 | 9,57 giây | 13,79 giây |
Nhìn chung, kết quả tuân theo sát định luật Amdahl. Mặc dù Xuất lượng tăng lên khi có nhiều Threads hơn, tổng thời gian thực thi bị giới hạn bởi giao dịch dài nhất. Với 16 Threads , các giao dịch dài nhất chiếm khoảng 75% tổng thời gian thực thi, giới hạn tốc độ tăng chỉ còn khoảng 4 lần thay vì mức lý tưởng là 16 lần.
Để khắc phục hạn chế này, chúng tôi đã cố gắng tăng Gas Limit Block .
Khi số luồng vượt quá số lõi vật lý (ví dụ: 32 Threads trên 16 lõi), hiệu năng sẽ không còn được cải thiện nữa. Mặc dù bản thân I/O có thể mở rộng vượt quá số lõi vật lý, nhưng điều này có thể bị giới hạn bởi việc tra cứu bộ nhớ cache của RocksDB (chỉ mục, bộ lọc Bloom, khối dữ liệu) và việc mã hóa/giải mã giá trị tốn nhiều tài nguyên CPU.
Khối Mega cho phép xử lý song song quy mô lớn
Để khắc phục giới hạn đường dẫn quan trọng trên mỗi khối, chúng tôi đã thử nghiệm với các "khối lớn" có mức gas cao hơn như trong công trình trước đây để tăng tính song song. Để mô phỏng điều này, chúng tôi đã thực hiện các giao dịch của nhiều khối mạng chính liên tiếp, cụ thể là một Block lớn hoặc một lô giao dịch, song song, và sau đó chỉ ghi trạng thái vào cơ sở dữ liệu sau khi tất cả các giao dịch trong lô đã hoàn tất. Điều này giúp tổng hợp nhiều khối thành một đơn vị thực thi lớn duy nhất.
Chúng tôi đã đánh giá một lô 50 khối, mô phỏng mức sử dụng gas trung bình Block là 1.121 MB, trên các số luồng khác nhau. Kết quả đầy đủ được hiển thị bên dưới:
| Threads | Xuất lượng (mg gas/giây) | Độ trễ TX dài nhất | Tổng thời gian |
|---|---|---|---|
| 1 | 943 | 0,53 giây | 47,55 giây |
| 2 | 1.857 | 0,53 giây | 24,16 giây |
| 4 | 3.505 | 0,56 giây | 12,80 giây |
| 8 | 6.524 | 0,57 giây | 6,88 giây |
| 16 | 10.842 | 0,61 giây | 4,13 giây |
| 32 | 10.794 | 1,07 giây | 4,14 giây |
Với các khối lớn (mega blocks), các giao dịch chạy lâu nhất không còn chiếm ưu thế trong đường dẫn quan trọng nữa—chúng chỉ đóng góp chưa đến 15% tổng thời gian thực thi với 16 Threads. Thông lượng Xuất lượng gần như tuyến tính với số lượng luồng, đạt khoảng 10,8 GGas/giây—78% hiệu suất của BAL đầy đủ—trong khi vẫn duy trì mức giảm 67% kích thước BAL so với BAL đầy đủ.
| Thiết kế BAL | Kích thước BAL được mã hóa RLP | Xuất lượng với 16 Threads |
|---|---|---|
| BAL đầy đủ | 213 KB | 13.881 Mgas/giây |
| BAL đầu vào/đầu ra BAL | 71 KB (33% của 213 KB) | 10.842 Mgas/giây |
Phần kết luận
Nghiên cứu này chứng minh rằng BAL I/O song song đạt được hiệu suất gần bằng BAL đầy đủ trong khi giảm đáng kể kích thước BAL . Trong các thiết lập mega-block, BAL I/O song song duy trì tốc độ xử lý khoảng 10,8 GGas/s (~78% Xuất lượng của BAL đầy đủ), đồng thời giảm chi phí kích thước BAL xuống còn khoảng 33% so với BAL đầy đủ. Điều này làm cho BAL I/O song song trở thành một lựa chọn thiết kế thiết thực và hiệu quả, cân bằng giữa Xuất lượng và chi phí mạng và lưu trữ.
Nhìn chung, những kết quả này thiết lập một giới hạn trên thực tế cho việc thực thi song song dựa trên BAL I/O và cung cấp những hiểu biết hữu ích cho việc tối ưu hóa máy khách Ethereum và các nỗ lực mở rộng L1 trong tương lai.
Các tác phẩm khác
Ngoài các bài kiểm tra hiệu năng, chúng tôi đã so sánh RocksDB và MDBX dưới các tác vụ đọc ngẫu nhiên tổng hợp và thực thi Máy ảo Ethereum (EVM) , đồng thời xem xét sự đánh đổi giữa BAL I/O song song và BAL I/O theo lô trên các giới hạn gas Block khác nhau.
So sánh hiệu năng đọc ngẫu nhiên giữa MDBX và RocksDB.
Đầu tiên, chúng tôi đã đánh giá hiệu năng đọc ngẫu nhiên thô của MDBX và RocksDB trên cùng phần cứng được sử dụng trong các thí nghiệm trước đó, thay đổi số lượng Threads đọc để đánh giá khả năng mở rộng. Cấu hình cơ sở dữ liệu như sau:
| Mục | Giá trị |
|---|---|
| Kích thước chìa khóa | 16 byte |
| Kích thước giá trị | 32 byte |
| Các mục nhập | 1,6 tỷ |
| Kích thước RocksDB | 85 GB |
| Kích thước MDBX | 125 GB |
Kết quả chi tiết:
| Threads | Cơ sở dữ liệu | IOPS | Độ trễ trung bình (µs) | Mức sử dụng CPU (%) |
|---|---|---|---|---|
| 2 | RocksDB | 12K | 160 | 1.1 |
| 2 | MDBX | 21 nghìn | 85 | 0,8 |
| 4 | RocksDB | 30 nghìn | 130 | 2.2 |
| 4 | MDBX | 48K | 84 | 1.3 |
| 8 | RocksDB | 85 nghìn | 92 | 4,5 |
| 8 | MDBX | 97K | 83 | 2,5 |
| 16 | RocksDB | 180K | 90 | 8 |
| 16 | MDBX | 180K | 86 | 6 |
| 32 | RocksDB | 320K | 110 | 24 |
| 32 | MDBX | 360K | 90 | 13 |
Cả RocksDB và MDBX đều Xuất lượng gần như tuyến tính với số lượng luồng, ngay cả khi vượt quá 16 lõi vật lý. Khi số lượng luồng vượt quá 8, sự khác biệt về IOPS và độ trễ giữa hai cơ sở dữ liệu trở nên rất nhỏ.
Bộ công cụ đo hiệu năng có sẵn tại: GitHub - dajuguan/ioarena: Công cụ đo hiệu năng lưu trữ nhúng cho libmdbx, rocksdb, lmdb, ETC
So sánh hiệu năng thực thi Máy ảo Ethereum (EVM) giữa MDBX và RocksDB với thiết lập I/O song song.
Tiếp theo, chúng tôi đánh giá Xuất lượng thực thi Máy ảo Ethereum (EVM) với I/O song song sử dụng MDBX và so sánh với RocksDB, với mức sử dụng gas Block là 1.121 M. Kết quả chi tiết:
| Threads | Cơ sở dữ liệu | Xuất lượng (mg gas/giây) |
|---|---|---|
| 8 | MDBX | 2.369 |
| 8 | RocksDB | 6.524 |
| 16 | MDBX | 3.705 |
| 16 | RocksDB | 10.842 |
| 32 | MDBX | 5.748 |
| 48 | MDBX | 6.662 |
| 64 | MDBX | 6.525 |
Mặc dù hiệu năng I/O thô tương tự nhau, Xuất lượng thực thi với MDBX lại thấp hơn đáng kể. Sự khác biệt này có thể là do cách sử dụng hiện tại của liên kết MDBX của reth, vốn chưa khai thác triệt để khả năng song song hóa I/O tiềm ẩn. Cụ thể, việc quản lý đúng cách các trình đọc dùng chung giữa Threads có thể cải thiện hiệu năng, nhưng chúng tôi vẫn chưa tìm ra phương pháp hiệu quả.
So sánh I/O song song và I/O theo lô qua các giới hạn gas
Phân tích trước đây chủ yếu tập trung vào I/O song song, trong đó trạng thái được lấy theo yêu cầu trong quá trình thực thi. Tuy nhiên, I/O theo lô có thể mang lại lợi thế trong các trường hợp một số giao dịch đòi hỏi nhiều I/O và có thể khai thác tốt hơn tính song song của I/O vượt quá số lượng lõi CPU vật lý.
Để đánh giá sự đánh đổi này, chúng tôi đã so sánh BAL I/O song song và BAL I/O theo lô trên các mô hình tải I/O khác nhau, và đo lường mức độ thay đổi Xuất lượng thực thi dưới hai thiết kế BAL này.
Phân tích tải I/O trung bình với dữ liệu Mainnet
Chúng ta bắt đầu với phân tích trường hợp trung bình, trong đó việc đọc dữ liệu từ bộ nhớ chỉ chiếm một phần nhỏ trong tổng số lệnh được thực thi trong mỗi giao dịch — một thiết lập phản ánh khá sát với khối lượng công việc điển hình trên mạng chính. Bảng sau đây tóm tắt kết quả Xuất lượng dưới các thiết kế BAL khác nhau, số lượng luồng và mức sử dụng gas Block .
| Loại I/O | Threads | Kích thước lô Block | Gas Block (M) | Xuất lượng (mg gas/giây) |
|---|---|---|---|---|
| Theo lô | 16 | 1 | 22 | 3.587 |
| Theo lô | 32 | 1 | 22 | 3.333 |
| Song song | 16 | 1 | 22 | 2.893 |
| Theo lô | 16 | 10 | 224 | 7.221 |
| Theo lô | 32 | 10 | 224 | 6.725 |
| Song song | 16 | 10 | 224 | 6.842 |
| Theo lô | 16 | 50 | 1.121 | 10.159 |
| Theo lô | 32 | 50 | 1.121 | 10.259 |
| Song song | 16 | 50 | 1.121 | 10.842 |
| Theo lô | 16 | 100 | 2.243 | 11.129 |
| Theo lô | 32 | 100 | 2.243 | 11.266 |
| Song song | 16 | 100 | 2.243 | 11.292 |
Khi mức sử dụng gas Block tăng lên, Xuất lượng tiếp tục tăng đối với cả hai thiết kế. Tuy nhiên, lợi thế tương đối của BAL I/O theo lô giảm dần, từ khoảng 20% ở kích thước Block nhỏ xuống gần bằng không ở kích thước Block lớn .
Ngoài ra, việc tăng số Threads từ 16 lên 32 cho I/O BAL theo lô không mang lại nhiều lợi ích về hiệu năng, cho thấy khối lượng công việc bị giới hạn bởi CPU hơn là I/O. Hiện tượng này có thể là do việc tra cứu bộ nhớ cache RocksDB và mã hóa/giải mã giá trị tốn nhiều tài nguyên CPU, làm hạn chế khả năng mở rộng I/O hơn nữa.
| Thiết kế BAL | Kích thước BAL được mã hóa RLP |
|---|---|
| BAL I/O BAL (không đọc) | 110 KB |
| BAL I/O BAL (có đọc) | 71 KB (nhỏ hơn 35%) |
Điều quan trọng cần lưu ý là kích thước BAL được mã hóa RLP trung bình cho I/O theo lô lớn hơn khoảng 35% so với I/O song song. Do các khối lớn làm lộ ra các điểm nghẽn thực thi không chỉ riêng việc đọc I/O, nên chi phí mạng và lưu trữ bổ sung này khiến I/O song song trở thành lựa chọn thiết kế BAL hấp dẫn hơn về tổng thể . Các phép đo kích thước BAL chi tiết cũng có sẵn trong bộ công cụ đánh giá hiệu năng ở trên .
Phân tích tải I/O trường hợp xấu nhất với dữ liệu mô phỏng
Để bổ sung cho kết quả trung bình, chúng ta sẽ xem xét kịch bản tải I/O tồi tệ nhất, trong đó việc đọc dữ liệu từ đĩa chiếm ưu thế trong quá trình thực thi giao dịch.
Để mô phỏng thiết lập này, chúng tôi xây dựng các giao dịch tổng hợp nhằm tối đa hóa áp lực truy cập bộ nhớ. Cụ thể, chúng tôi tạo ra các giao dịch có luồng mã lệnh chứa đầy các lệnh gọi đến một hợp đồng thực hiện các thao tác SLOAD(x) lặp đi lặp lại, trong đó x là Hash của một giá trị ngẫu nhiên. Nếu không có các vị trí đọc do BAL cung cấp, các giao dịch như vậy phải thực hiện các mã lệnh SLOAD theo trình tự để lấy trạng thái bộ nhớ, thể hiện khối lượng công việc bị giới hạn bởi I/O trong trường hợp xấu nhất.
Với Gas Limit hiện tại cho mỗi giao dịch là 16 triệu gas và chi phí đọc trạng thái cho mỗi khe lưu trữ xấp xỉ:
- 2000 gas cho
SLOAD, cộng thêm khoảng 39 gas cho chi phí xử lý Hash keccak.
Một giao dịch đơn lẻ có thể thực hiện tối đa: \frac{16{,}000{,}000}{2039} \approx 7{,}845 16,000,000 2039 ≈ 7.845
các thao tác đọc bộ nhớ riêng biệt. Sử dụng cấu hình này, chúng tôi mô phỏng các giao dịch tải I/O trường hợp xấu nhất với cơ sở dữ liệu mạng chính.
Bảng so sánh hiệu năng giữa thiết kế I/O theo lô và song song được thể hiện bên dưới:
| Loại I/O | Threads | Tổng thời gian thực thi (ms) | Gas Block (M) | Xuất lượng (mg gas/giây) |
|---|---|---|---|---|
| Theo lô | 16 | 14.4 | 64 | 4.571 |
| Theo lô | 32 | 11.2 | 64 | 5.818 |
| Theo lô | 48 | 10.7 | 64 | 6.400 |
| Theo lô | 64 | 10.7 | 64 | 5.333 |
| Song song | 4 | 82,5 | 64 | 780 |
| Theo lô | 16 | 42,6 | 640 | 11.034 |
| Theo lô | 32 | 58,2 | 640 | 12.307 |
| Theo lô | 32 | 60,3 | 640 | 10.158 |
| Song song | 16 | 82,2 | 640 | 7.804 |
Với mức sử dụng gas Block thấp hơn (64M gas), BAL I/O theo lô đạt được Xuất lượng tốt nhất ở 48 Threads, đạt Xuất lượng gần gấp 8 lần so với BAL I/O song song . Điều này xác nhận rằng việc nhóm I/O một cách rõ ràng rất hiệu quả khi các thao tác đọc dữ liệu từ bộ nhớ chiếm ưu thế trong quá trình thực thi.
Tuy nhiên, điều quan trọng là phải diễn giải các kết quả này trong bối cảnh thực thi từ đầu đến cuối. Ngay cả trong kịch bản tải I/O tồi tệ nhất, tổng thời gian thực thi cho BAL I/O song song vẫn thấp hơn nhiều so với thời hạn chứng thực hiện tại (~3 giây). Hơn nữa, vì không có thay đổi trạng thái trong trường hợp này, việc thực thi song song loại trừ chi phí Merklization và cam kết trạng thái, chiếm gần 50% tổng thời gian thực thi trong các đường ống thực thi song song thực tế.
Trong thiết lập khối lớn sử dụng khí gấp 10 lần (640 M gas), khoảng cách hiệu năng thu hẹp hơn nữa: BAL I/O theo lô chỉ vượt trội hơn BAL I/O song song khoảng ~1,6 lần , trong khi cả hai đều nằm trong giới hạn thời gian xác thực.
| Loại I/O | Gas Block (M) | Xuất lượng tối ưu (MGas/s) | Kích thước BAL được mã hóa RLP |
|---|---|---|---|
| Theo lô | 64 | 6.400 | 251 kb |
| Song song | 64 | 6.400 | 0 kb |
| Theo lô | 640 | 15.238 | 2.511 kb |
| Song song | 640 | 6.153 | 0 kb |
Nhìn chung, trong điều kiện tải I/O nặng nề nhất, chúng ta quan sát thấy những điều sau:
- Theo giới hạn gas hiện hành của mạng lưới chính:
- BAL I/O theo lô đạt được Xuất lượng cải thiện gấp 8 lần so với BAL I/O song song. Tuy nhiên, khi xem xét thời gian xử lý Block từ đầu đến cuối, việc đọc I/O không phải là nút thắt cổ chai chính trong chế độ này.
- Dưới giới hạn gas 10×:
- Ưu thế về hiệu năng của BAL I/O theo lô giảm đáng kể , chỉ mang lại Xuất lượng 1,6 lần so với BAL I/O song song, đồng thời phát sinh thêm khoảng 2,5 MiB dung lượng BAL dư thừa, một con số không thể bỏ qua.
Những kết quả này củng cố một nhận định quan trọng: mặc dù BAL I/O theo lô mang lại hiệu suất tốt nhất trong điều kiện tải công việc bão hòa I/O, BAL I/O song song vẫn đủ mạnh mẽ ngay cả trong những trường hợp xấu nhất — mà không phải chịu thêm chi phí về kích thước BAL do việc xử lý theo lô gây ra.
Bộ công cụ so sánh hiệu năng có sẵn tại đây: GitHub - dajuguan/evm-benchmark
