Performance issue while reading the data with FLAC file format via HTTP.
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 45/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- python
調査の方向性
mimic3wdb、mitdb、mimic4wdb について、提供されている wfdb.rdsamp のタイミング例を再現します。その後、_url.py と soundfile.py の _cdata_io パスを調べ、読み取り呼び出しの繰り返しと buffering=-2 の動作に注目します。FLAC-over-HTTP のケースで不要な HTTP 通信が回避され、サーバーへのリクエスト数を増やさずにタイミングが改善されれば完了です。
索引モデルが issue の本文から書いたものです。
説明
I tested the performance of wfdb python library for reading waveforms via HTTP.
- mimic3wdb
dtstart = datetime.datetime.now()
wfdb.rdsamp('3000003', pn_dir='mimic3wdb/1.0/30/3000003')
print(datetime.datetime.now() - dtstart)
# results 0:00:21.143365
- mitdb
dtstart = datetime.datetime.now()
wfdb.rdsamp('100', pn_dir='mitdb/1.0.0')
print(datetime.datetime.now() - dtstart)
# results 0:00:02.764091
It looks great. However, when I tried to read the mimic4wdb which has FLAC format, there was a significant performance decrease.
- mimic4wdb
dtstart = datetime.datetime.now()
wfdb.rdsamp('81739927', pn_dir='mimic4wdb/0.1.0/waves/p100/p10014354/81739927')
print(datetime.datetime.now() - dtstart)
# results 0:07:26.220685
This issue was resolved when I cached files with the buffering = -2 for openurl function in _url.py.
-> results 0:00:37.388115
After digging a bit more, I figured out that this problem is caused by repeatedly calling read function frame by frame in the _cdata_io function in soundfile.py. Whenever the read function is called, session.request in _url.py is called and HTTP communication is established. This can cause significant performance problem and also make stress to the web server.
So it seems a good idea to change buffering=-2 to default until this is fixed. Reducing the number of requests is much more efficient in both improving the performance and reducing the load of the web server.
- 主要言語
- Jupyter Notebook
- スター
- 853
- フォーク
- 322
- PR マージ指標
- 30日以内にマージされた PR はありません
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
MIT-LCP/wfdb-python のほかの issue
-
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
MIT-LCP/wfdb-python#568 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 48/100
MIT-LCP/wfdb-python#557 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 58/100
MIT-LCP/wfdb-python#554 ·
-
WFDB path ignored オープン
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
MIT-LCP/wfdb-python#545 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
MIT-LCP/wfdb-python#540 ·
MIT-LCP/wfdb-python の issue をすべて見る
似ている issue
-
Bug Java Platform: Java
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
getsentry/sentry-java#6138 · コメント 1 件 ·
-
kind/bug Ubuntu 24
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
kubernetes-sigs/kubespray#13532 ·
-
language/en needs-triage sig/network
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
kubernetes/website#57642 · コメント 1 件 ·
-
app.loanspq.com オープンN: AdGuard DNS P3: Medium T: Incorrect Blocking
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
AdguardTeam/AdguardFilters#242018 ·
-
[adam] AdamNet network read doesn't cap to MAX_ADAM_PACKET_LEN, overflows client receive buffers オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
FujiNetWIFI/fujinet-firmware#1649 · コメント 2 件 ·