As more CSPs provide HTTP2 (latest: OneDrive) more rclone users run into performance issues.
Go apparently can't (at least: Won't) fix their bug so I deemed it way better to disable HTTP2 by default and have a switch --enable-http2 to actually use it (it saved users from troubleshooting and providers from performance complaints).
P.S. For backwards compatibility pls keep --disable-http2 nevertheless, though w/o function then
Just tested: rclone 1.70 is still the same, terrible performance if the provider supports HTTP2 and it's not disabled in rclone command.
Do you know since when OneDrive supports HTTP2 by default? I can't place a point in time where OneDrive performance dropped for me (it has always been bad).
Could you share what and how you tested? For me OneDrive performance is the same with or without HTTP2.
VPS with 1+ Gbps
rclone.exe sync Drive:/[path] onedrive:/[path] --transfers 8 --checkers 16 --delete-before --fast-list --order-by="size,mixed,50" --create-empty-src-dirs --progress
w/o --disable-http2 it's singlethreaded (1 tcp connection to OD) and maxes out at 40 Mbps, /w --disable-http2 it's multithreaded (didn't count, 10++ tcp connections) and achieves ~200 Mbps.
Dunno, a few weeks?
It's only backing up my primary cloud storage to my secondaries, so I only keep 7d log.
edit: I don't know if/that OneDrive does support HTTP2, I only saw the bad performance and was reminded of Koofrs issue.
Tried the same solution (--disable-http2) and achieved similar result (significant performance boost).
This is worth discussing I think.
We can change the default for disabled http2 to true very easily and you'd counter that with --disable-http2=false
What would we break by doing that?
Http2 can improve latency so if you are making 1000s of requests a second you might notice.
Perhaps we need some benchmarks with popular providers.
I just ran a couple of 'rclone copy's from a OneDrive remote to local storage using http2 and not. Speed was the same.
Are there any other parameters or circumstances that may cause a difference?
@dinosim IIRC I only noticed the diff for uploads, not downloads (IKR! pretty strange...)
@all due to a bigger emergency I'm overloaded ATM. Will do another testing / data presentation (hopefully) within a week.
I would suggest you test it multiple times, on different days and different weeks.
I have multiple OneDrive remotes, and I get wild variation in the upload speeds. Sometimes it starts at 25MBytes/s (per file) and stays there, more often it starts at that value and drops to about 10-15, sometimes it starts at 10MB/s and stays there, other times it drops further, and occasionally it drops to KB/s every few minutes during a transfer.
Aside from onedrive - the koofr backend affected by same issue.
I have some scripts to automate my restic backups to different cloud providers and there is annoying special cases for koofr all over the place.
I think changing default makes sense if there is an issue in the library that close uses. Another suggestion would be to make it a config file (by provider) option)
Why do you suggest I only tested sporadically?
I have cron jobs running on a VPS doing hourly syncs of pCloud to Koofr, OneDrive and a 3rd CSP, daily 10+ GB to each and the max 40 Mbps to OD were a constant.
What would take time is to set up a real test scenario.
On the other hand it appears as usual with vendors: Building my own workaround is way less time consuming than to convince the vendor sth is wrong.
Koofr was the provider I 1st reported this behavior for (~2y ago?). Back then we found out it's a bug Go that obviously hasn't been fixed until today.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.