Massive regression in download speed in Seafile Windows client 9.0.7

[Makumasa]

I use the Seafile desktop client on multiple machines on my home network, which I use to sync files to/from a Seafile server also running on my home network. Recently, I've noticed that the download speed in the client has been very slow. For example, on my PC, my download speeds would typically range between 100-140 MB/s, but they were now 10-30 MB/s. Running a speed test confirmed that my machine's network performance hadn't changed, and downloading the same file via the Seafile web UI was substantially faster, indicating that the client was the most likely culprit. In my attempts to troubleshoot this issue, I tried the following:

• Using a different machine
• Downloading one large file
• Downloading many small files
• Downloading from an unencrypted library
• Downloading using a different user
• Upgrading the client to 9.0.8

None of these resolved the issue. No matter what I tried, the download speed would never exceed 30 MB/s, and would typically hover around 17 MB/s. My brother's laptop, however, was getting download speeds above 100 MB/s on the same network. After discovering that his client was still on version 9.0.6, I tried rolling back my machines to 9.0.6, and sure enough the throughput returned to what I'd expect.

I tried looking through the client logs, but didn't find anything out of the ordinary, so I'm not sure what the root cause is. The most I can say with any confidence is that the regression appears to have been introduced between versions 9.0.6 and 9.0.7 of the Seafile Windows client. I am unsure if the Linux/Mac clients are impacted, as I haven't tested those.

[killing]

In 9.0.7 version we modified the download process to directly write the downloaded data into the final file. In previous versions the data was written first into a temp file in internal cache folder then write to the user-visible file. The purpose of this change is to reduce the potential cache size limitation when downloading large files. We'll analyze the code for performance issues.

[Makumasa]

In 9.0.7 version we modified the download process to directly write the downloaded data into the final file. In previous versions the data was written first into a temp file in internal cache folder then write to the user-visible file. The purpose of this change is to reduce the potential cache size limitation when downloading large files. We'll analyze the code for performance issues.

Sounds good. Let me know if you'd like me to provide any additional information from my client or the tests I ran. As far as I can tell, the issue is trivial to reproduce.

[killing]

This is fixed in 9.0.9. Please test it again. Note that the speed for encrypted library is not improved, to avoid over-complicated logic.

The change that initially introduce this regression is that we changed to checkout file contents after downloading each block. Previously we checkout the files in batch after all blocks are downloaded. A drawback of the old approach is that it can take a lot of cache space if large files are downloaded. With this change, the delay when writing a block to file somehow triggers the OS to reset TCP windows, which reduces the download speed. For non-encrypted libraries it's possible to improve this by writing the data to file after reading it from the connection. For encrypted libraries it's not possible as we can only decrypt a block after receiving the entire block.

The original change: #2781
and the fix: #2834

I'll leave this issue open as encrypted library is not fixed.

[Makumasa]

Happy to hear it! I'll update and test shortly.

[Makumasa]

Alright, just tested on 9.0.9 on Windows and I can confirm that the download speed regression seems to be fixed for unencrypted libraries, but not for encrypted libraries.

Since I use encrypted libraries, I'll hold off on updating my systems until the issue is fixed for encrypted libraries, as well. Thanks again!