Improve drive sync algorithm to greatly improve performance
Proton Drive is extremely slow to upload my files, it's going at around ~200 Kbps, whereas speedtest.net shows I can do 3.62 Mbps upload.
This is especially noticeable when there is a large number of small files to sync (eg, photo collection).
I suspect that a potential cause is that new threads might be created to upload each individual file, resulting in the unnecessary opening and closing of many connections. Perhaps a better solution would be for each upload thread to establish a continuous connection and then pipe multiple files through that connection as raw data, which can be split back out into individual files on the server side.
Another possible cause is that this is intentional, with Proton Drive having a rate limited upload in order to not disrupt user applications. If this is the case, then I would greatly appreciate as a user having the ability to control this throttle to speed up the upload when I want to.
If there is no internal rate limiting, then at the very least, the number of simultaneous upload threads could be increased dynamically until the sum total of all connections stops improving by adding more threads. This could greatly improve upload rate, though probably would not be able to achieve as high a bandwidth as my first suggestion.
-
JP commented
I at least require the ability to limit or control the bandwidth allocated to sync operations in the desktop application, or limit the number of concurrent uploads/downloads. The current behaviour is both slow and inefficiently eating up all my bandwidth. It seems very similar to Microsoft's OneDrive which is just as inefficient (and what I was hoping to replace with Proton Drive), but it at least has a setting to limit upload and download rates.
-
Eric Wilson commented
The sync is unusable for a professional that routinely takes online meetings. I have a ton of upload bandwidth, but I always have to pause the ProtonDrive sync before getting on a call. The disruption to my calls actually took several days to figure out what was causing it. It's kind of wild that the upload from ProtonDrive is as slow as it is but it also manages to throw so much sand in the gears of my computer's network connection.
(this is on a Mac M3 Max with 64GB RAM if that matters)
-
Nick commented
My upload is attrociuos - 0.1Mbps
I get that's my issue - what I would love, to aliviate this somewhat, is control on upload threads
The Drive app itslef (macOS) literally kills my internet, RTA on pings to 1.1.1.1 go from 10ms to multiple (8-10) seconds with 50-60 actual packet LOSS when uploading.
If I could drop simultaneous uploads to 1 or 2 that would somewhat help. I'd like that granular control on the apps and the webUI if possible and I'm sure it would help others with low bandwidth scenarios.
-
J.A commented
Was that when it was first synced and do transfer speeds improve over time?
Why:
If P'Drive uses data deduplication under the hood the first copy to cloud will always be slow. As time goes on more data is synced to the cloud the more efficient deduplication is. -
Stuart Heinrich commented
Proton Drive is extremely slow to upload my files, it's going at around ~200 Kbps, whereas speedtest.net shows I can do 3.62 Mbps upload.
This is especially noticeable when there is a large number of small files to sync (eg, photo collection).
I suspect that a potential cause is that new threads might be created to upload each individual file, resulting in the unnecessary opening and closing of many connections. Perhaps a better solution would be for each upload thread to establish a continuous connection and then pipe multiple files through that connection as raw data, which can be split back out into individual files on the server side.
Another possible cause is that this is intentional, with Proton Drive having a rate limited upload in order to not disrupt user applications. If this is the case, then I would greatly appreciate as a user having the ability to control this throttle to speed up the upload when I want to.
If there is no internal rate limiting, then at the very least, the number of simultaneous upload threads could be increased dynamically until the sum total of all connections stops improving by adding more threads. This could greatly improve upload rate, though probably would not be able to achieve as high a bandwidth as my first suggestion.