[Performance] RDT vs Direct YuanrongStore Backend Performance Analysis
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- python
- Lĩnh vực
- backend, performance
Hướng nghiên cứu
Bắt đầu với các đường dẫn backend của TransferQueue RDT và YuanrongStore, trước tiên tập trung vào RayStorageClient.get và yr.get, sau đó tái hiện các phép so sánh TQ-RDT-YR và TQ-YR đã được báo cáo ở 16 GB. Công việc được xem là hoàn tất khi xác định được lý do thời gian của TQ Client tăng mạnh ở kích thước đó và ghi lại liệu batching hay việc truyền theo từng khóa có giải thích cho khác biệt quan sát được hay không.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Background
Currently, TransferQueue supports multiple transmission backends, including:
-
RDT (Ray Direct Transport): The native distributed transmission mechanism of Ray, usually using NIXL as the underlying transmission between GPUs
-
YR (YuanrongStore): A high-performance data transmission system optimized for the NPU architecture, similar in function to NIXL but more suitable for the Ascend hardware
The purpose of this issue is to benchmark and analyze the performance overhead introduced by RDT (Ray Distributed Object Store) when using DS as the transmission backend. We conducted a comparative test between two scenarios on NPU cross-node environments:
-
TQ-RDT-YR: TransferQueue using RDT as the backend, where RDT uses YuanrongStore for data transmission.
-
TQ-YR: TransferQueue using YuanrongStore directly for data transmission.
Key Objectives
Evaluate the performance cost of the RDT layer.
Test Results
TQ-RDT-YR Get Cost
| seq_length | total_size | TQ CLIENT get (s) | Ray Storage Client get (s) | BandWidth (GB/s) | BW_RayStorageClient (GB/s) |
|---|---|---|---|---|---|
| 32 KB | 64MB | 0.86 | 0.85 | 0.07 | 0.07 |
| 128 KB | 256MB | 0.85 | 0.83 | 0.30 | 0.30 |
| 512 KB | 1 GB | 0.93 | 0.91 | 1.07 | 1.10 |
| 1 MB | 2 GB | 0.95 | 0.94 | 2.10 | 2.13 |
| 2 MB | 4 GB | 1.13 | 1.11 | 3.55 | 3.61 |
| 4 MB | 8 GB | 1.43 | 1.41 | 5.58 | 5.68 |
| 8 MB | 16 GB | 13.60 | 1.80 | 1.18 | 8.88 |
TQ-YR Get Cost
| seq_length | total_size | TQ CLIENT get (s) | Ray Storage Client get (s) | BandWidth (GB/s) | BW_RayStorageClient (GB/s) |
|---|---|---|---|---|---|
| 32 KB | 64MB | 0.14 | 0.12 | 0.46 | 0.52 |
| 128 KB | 256MB | 0.15 | 0.13 | 4.69 | 1.87 |
| 512 KB | 1 GB | 0.14 | 0.12 | 7.18 | 8.07 |
| 1 MB | 2 GB | 0.17 | 0.15 | 12.10 | 13.35 |
| 2 MB | 4 GB | 0.26 | 0.25 | 15.20 | 16.21 |
| 4 MB | 8 GB | 0.51 | 0.47 | 15.71 | 17.13 |
| 8 MB | 16 GB | 12.77 | 0.90 | 1.25 | 17.85 |
Proposed Analysis
Regarding the reason for the time difference in the RayStorageClient.get in the two scenarios, we speculate that it is because YRStore performs batch processing, getting all items together in one batch, while RayStore processes them individually. Each key is a separate reference, and even when calling yr.get, only one can be transferred at a time.
Remaining doubts
- When the total data volume reached 16GB, the time taken from the
TQ ClienttoRayStore/YRStoresuddenly increased significantly. Looking at the green section in the figure below, you can see that it suddenly expands significantly when the capacity reaches 16GB.
- Ngôn ngữ chính
- Python
- Star
- 168
- Fork
- 56
- Merge trung bình
- 4 ngày 1 giờ
- Pull request đã merge (30 ngày)
- 15
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của Ascend/TransferQueue
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Ascend/TransferQueue#194 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[doc] Document the contract of storage-side callables (data_parser, merge_fn) with a tutorialĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
Ascend/TransferQueue#195 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 30/100
Ascend/TransferQueue#188 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
Ascend/TransferQueue#180 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
Ascend/TransferQueue#173 · 2 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của Ascend/TransferQueue
Issue tương tự
-
link-rot
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 67/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
developmentseed/titiler-cmr#265 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Insecure Brotli version <1.2.1Có thể đã có người làm @jamescw19 đã nhận hôm nay. Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 85/100
stac-utils/stac-fastapi-pgstac#438 · 1 reaction ·
-
bug triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
Maintainer thường phản hồi trong vòng 1 ngày