OpenListTeam / OpenListTeam/OpenList
[Feature] 跨网盘间复制转存队列优化建议
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 24.7k
- Forks
- 2.3k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 36
Description
请确认以下事项
-
我已确认阅读并同意 AGPL-3.0 第15条 。
本程序不提供任何明示或暗示的担保，使用风险由您自行承担。 -
我已确认阅读并同意 AGPL-3.0 第16条 。
无论何种情况，版权持有人或其他分发者均不对使用本程序所造成的任何损失承担责任。 -
我确认我的描述清晰，语法礼貌，能帮助开发者快速定位问题，并符合社区规则。
-
我已确认阅读了OpenList文档。
-
我已确认没有重复的问题或讨论。
-
我认为此问题必须由
OpenList处理，而非第三方。 -
我已确认此功能尚未被实现。
-
我已确认此功能是合理的，且有普遍需求，并非我个人需要。
需求描述
通过观察上下行带宽得知，目前的边下边传策略是下载目标网盘的分片大小，下载完一个分片后开始上传，上传完成后开始下载第二个分片依次循环……
这样的策略会导致上行带宽始终会断断续续不能持续占满，建议优化为队列中始终存在两个分片以持续占满上行带宽
实现思路
增加一个分片等待上传
附加信息
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No source files or tests are named in the issue. Start by locating the cross-cloud segmented copy/transfer path and inspect how it schedules downloads and uploads; done means the queue keeps two chunks waiting for upload and sustains upstream usage, with relevant tests covering the scheduling behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend, performance
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100