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
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).
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).
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.