[Performance] RDT vs Direct YuanrongStore Backend Performance Analysis
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- python
- Ambito
- backend, performance
Direzione di ricerca
Inizia con i percorsi backend di TransferQueue RDT e YuanrongStore, concentrandoti prima su RayStorageClient.get e yr.get, quindi riproduci i confronti TQ-RDT-YR e TQ-YR riportati a 16 GB. Il lavoro è completato quando viene identificato il motivo per cui il tempo di TQ Client aumenta nettamente a quella dimensione e viene documentato se il batching o i trasferimenti per chiave spiegano la differenza osservata.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- Python
- Stelle
- 168
- Fork
- 56
- Merge medio
- 4g 1h
- PR unite (30g)
- 15
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Ascend/TransferQueue
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
Ascend/TransferQueue#194 ·
I maintainer di solito rispondono entro 1 giorno
-
[doc] Document the contract of storage-side callables (data_parser, merge_fn) with a tutorialAperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
Ascend/TransferQueue#195 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
Ascend/TransferQueue#188 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
Ascend/TransferQueue#180 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
Ascend/TransferQueue#173 · 2 commenti · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di Ascend/TransferQueue
Issue simili
-
No test checks that scheduled workflows declare minimal permissions, concurrency and a timeoutApertaci enhancement testing
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
area/config comp/tools P2 platform/telegram type/bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
NousResearch/hermes-agent#145412 ·
I maintainer di solito rispondono entro 1 giorno
-
[oblt-aw][autodoc] Update docs for security org scaffolding and Docs AI menu permission changesForse già presa @github-actions l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno
-
curriculum documentation quality
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
githubnext/gh-aw-workshop#5039 ·
I maintainer di solito rispondono entro 1 giorno
-
Community project: hosted MOSS-Image studio with a visual JSON layout builder (no ComfyUI needed)Aperta
Difficoltà 1/5 1-3 ore Idoneità per principianti 65/100
OpenMOSS/MOSS-Image#27 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno