Windows desktop client 3.11.0 painfully slow data transfer

bsw · January 1, 2024, 4:40am

Nextcloud version (eg, 20.0.5): 28.0.1
Operating system and version (eg, Ubuntu 20.04): Ubuntu 22.04.3
Apache or nginx version (eg, Apache 2.4.25): whatever comes in Docker
PHP version (eg, 7.4): as above

The issue you are facing: syncing files to/from Windows desktop client 3.11.0 is very slow.

Is this the first time you’ve seen this error? (Y/N): N

Steps to replicate it:

Go to Windows explorer in Nextcloud sync. folder
Right click on 500MB file - select “Free up space”
Right click on 500MB file - select “Always keep on this device”
Go to admin. panel of LAN switch and watch throughput start at about 40Mbit/sec, stay there for about 200MB and then drop back to about 17Mbit/sec for the remainder of the file - it takes several minutes.

Both the client and server are on the same 1Gbit/s LAN. Transferring the same file between the same client and server using either a CIFS share or the Nextclound web interface happens in a few seconds at ~900Mbit/s.

I’m running the docker image server now, but had the exact same symptoms with the .tar.gz image extracted into an existing Apache server and MariaDB.

The output of your Nextcloud log in Admin > Logging:

Nothing

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'htaccess.RewriteBase' => '/',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'apps_paths' =>
  array (
    0 =>
    array (
      'path' => '/var/www/html/apps',
      'url' => '/apps',
      'writable' => false,
    ),
    1 =>
    array (
      'path' => '/var/www/html/custom_apps',
      'url' => '/custom_apps',
      'writable' => true,
    ),
  ),
  'upgrade.disable-web' => true,
  'instanceid' => 'xxx',
  'passwordsalt' => 'xxx',
  'secret' => 'xxx,
  'trusted_domains' =>
  array (
    0 => 'slug',
  ),
  'datadirectory' => '/var/www/html/data',
  'dbtype' => 'sqlite3',
  'version' => '28.0.1.1',
  'overwrite.cli.url' => 'http://slug',
  'dbname' => 'nextcloud',
  'installed' => true,
);

The output of your Apache/nginx/system log in /var/log/____:

Here are 3 gets of the same file in the logs - sync. client, browser and sync. client again.

192.168.2.15 - bwatson [31/Dec/2023:23:08:01 -0400] "GET /remote.php/dav/files/bwatson/random.file HTTP/1.1" 200 494716967 "-" "Mozilla/5.0 (Windows) mirall/3.11.0stable-Win64 (build 20231211) (Nextcloud, windows-10.0.22621 ClientArchitecture: x86_64 OsArchitecture: x86_64)"
192.168.2.15 - - [31/Dec/2023:23:10:29 -0400] "GET /remote.php/dav/files/bwatson/random.file HTTP/1.1" 200 494716968 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0"
192.168.2.15 - bwatson [31/Dec/2023:23:28:33 -0400] "GET /remote.php/dav/files/bwatson/random.file HTTP/1.1" 200 494716967 "-" "Mozilla/5.0 (Windows) mirall/3.11.0stable-Win64 (build 20231211) (Nextcloud, windows-10.0.22621 ClientArchitecture: x86_64 OsArchitecture: x86_64)"

Output errors in nextcloud.log in /var/www/ or as admin user in top right menu, filtering for errors. Use a pastebin service if necessary.

The following logs are from the setup - failed attempts and docker compose setups. The logs survived.

Warning core
Login failed: ‘bwatson’ (Remote IP: ‘192.168.2.15’)
Dec 31, 2023, 11:01:24 PM
Error index
InvalidArgumentException No proper share data
Dec 31, 2023, 11:01:19 PM
Warning no app in context
Host slug was not connected to because it violates local access rules
Dec 31, 2023, 11:00:21 PM
Warning no app in context
Host slug was not connected to because it violates local access rules
Dec 31, 2023, 11:00:21 PM
Warning no app in context
Host slug was not connected to because it violates local access rules
Dec 31, 2023, 11:00:21 PM
Warning no app in context
Host slug was not connected to because it violates local access rules
Dec 31, 2023, 11:00:21 PM
Warning no app in context
Host slug was not connected to because it violates local access rules
Dec 31, 2023, 11:00:21 PM
Warning no app in context
Host slug was not connected to because it violates local access rules
Dec 31, 2023, 11:00:21 PM

ernolf · January 1, 2024, 10:04am

What image: Apache or fpm?

Apache only can speak HTTP/1.1 while fpm can speak HTTP/2 which provides its own, more efficient, mechanisms for data streaming.

Besides much other issues which you can find here in the forum using the search function, you could give h2 a chance:

Much luck,
ernolf

tflidd · January 1, 2024, 12:30pm

It is no real database, and on top of that you don’t have redis cache (file-locking during data transfer). Performance-wise it is known to have important draw-backs. You should see a lot of io-waits on your server.

You’ll never get this performance, since there is some overhead with the database.

bsw · January 1, 2024, 2:25pm

I used the search function. The only posts I found with issues similar to mine had no resolution. One person said they “fixed” it by installing the Owncloud windows client but that was very old so I had dismissed it - I might try it now…

You are missing the key, IMHO, part of my problem - the server works just fine.

This takes a few seconds:
192.168.2.15 - - [01/Jan/2024:10:07:52 -0400] "GET /remote.php/dav/files/bwatson/random.file HTTP/1.1" 200 494716967 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0"

This takes a few minutes:
192.168.2.15 - bwatson [01/Jan/2024:10:08:17 -0400] "GET /remote.php/dav/files/bwatson/random.file HTTP/1.1" 200 494716967 "-" "Mozilla/5.0 (Windows) mirall/3.11.0stable-Win64 (build 20231211) (Nextcloud, windows-10.0.22621 ClientArchitecture: x86_64 OsArchitecture: x86_64)"

Edit to clarify - random.file is an actual file (made with dd if=/dev/random…), it’s not me editing the log to remove personal data.

This is my switch throughput while the transfers are happening. The spike up to ~800Mbit/s is the browser transfer, the dribble to the right is the start of the Windows Sync. Client transfer:

Unless the server is intentionally crippling the “Mozilla/5.0 (Windows) mirall/3.11.0stable-Win64 (build 20231211) (Nextcloud, windows-10.0.22621 ClientArchitecture: x86_64 OsArchitecture: x86_64)” user agent - this is a problem with the Windows client.

bsw · January 1, 2024, 2:29pm

Please see my reply to ernolf - there is no database involved here. My issue is data throughput with a single file transfer. I’m confident the sqlite3 dbtype will be sufficient for me use case.

ernolf · January 1, 2024, 2:52pm

Could you please post the content of your C:\Users\%USER%\AppData\Roaming\Nextcloud\nextcloud.cfg

ernolf

bsw · January 1, 2024, 3:45pm

Sure… “XXX” replacing personal data. I know I’ve already shared some above…

I should also add that I have previously, and stupidly, set the client to sync. the same folder as OneDrive. This caused the problems you might expect. I have since removed the Nextcloud client, and the various Nextcloud related AppData folders, and then re-installed. I’m wondering if there is some residual configuration from this (in the registry?) causing problems.

[General]
clientVersion=3.11.0stable-Win64 (build 20231211)
isVfsEnabled=false
updateSegment=87
optionalServerNotifications=true
overrideLocalDir=
overrideServerUrl=
showCallNotifications=true
showInExplorerNavigationPane=true

[Accounts]
version=2
0\FoldersWithPlaceholders\1\localPath=C:/Users/XXX/Nextcloud/
0\version=1
0\FoldersWithPlaceholders\1\journalPath=.sync_52183172521d.db
0\url=http://slug
0\FoldersWithPlaceholders\1\targetPath=/
0\dav_user=XXX
0\FoldersWithPlaceholders\1\paused=false
0\displayName=XXX
0\FoldersWithPlaceholders\1\ignoreHiddenFiles=false
0\serverVersion=28.0.1.1
0\FoldersWithPlaceholders\1\virtualFilesMode=wincfapi
0\serverColor=@Variant(\0\0\0\x43\x1\xff\xff\0\0\x82\x82\xc9\xc9\0\0)
0\FoldersWithPlaceholders\1\version=3
0\serverTextColor=@Variant(\0\0\0\x43\x1\xff\xff\xff\xff\xff\xff\xff\xff\0\0)
0\FoldersWithPlaceholders\1\navigationPaneClsid=@Variant(\0\0\0\x7f\0\0\0\x6QUuid\0JmI(q\x8e\x45O\x92\x14\xf0\xc3\x5\xdfKw)
0\webflow_user=XXX
0\authType=webflow

[BWLimit]
downloadLimit=100000
uploadLimit=100000
useDownloadLimit=0
useUploadLimit=0

[Proxy]
type=2

[Settings]
geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x3\0\0\0\0\x2\xbd\0\0\x1\x3\0\0\x4\xc2\0\0\x3\x16\0\0\x2\xbe\0\0\x1"\0\0\x4\xc1\0\0\x3\x15\0\0\0\0\0\0\0\0\a\x80\0\0\x2\xbe\0\0\x1"\0\0\x4\xc1\0\0\x3\x15)

bsw · January 2, 2024, 5:11am

OK, this is weird. The desktop client has a mind of its own!

It started working at expected speed for a while and I’ve changed nothing. I was checking to see the if my OneDrive had bandwidth throttling set just in case Microsoft somehow implemented this as a machine wide setting and not just OneDrive. After confirming that I did not have OneDrive throttled I tried syncing the big file again - this time it was different - it spiked up to ~400Mbit/s for about half the file then went down to 17Mbit/s for a while and then back up to ~40Mbit/s until the end. I thought that was strange so I tried again and the whole file synced in a few seconds at ~700Mbit/s. I did it a couple more times for good measure and the fast performance was repeated.

I was happy with download speed now so I copied a folder with about 20GB of video files into the sync folder and was very happy - it was uploading at ~600Mbit/s. Then one file generated a 413 Request Entity Too Large error. I did a bunch of reading and think I understand that this relates to chunk size, not absolute file size. Looking at the logs I can see that the client is dynamically calculating chunk sizes so I restarted and tried again. It completed syncing the folder with the speed fluctuating between 17Mbit/s and ~300Mbit/s. All this time the server is idle - CPU around 1% user, 1% system, 96% idle and 2% wait. I can go to a browser window and upload a file from the same client to the same server (the Nextcloud instance - not just the same physical server) at ~700Mbit/s while the sync is limping along at ~300.

I found a post suggesting that a fix for the 413 error is to add maxChunkSize=500000000 to the client config, which makes sense as the PHP config in the docker image I am using has upload_max_filesize => 512M => 512M.

And now I find that download sync is now back to running at ~300Mbit/s.

I’m not asking for any specific help now I guess - just venting. I’ll keep reading and testing but, this does not instill confidence. I’m confused that I seem to be the only one having these issues. Are others happy with the, relatively, slow sync speeds?

robnicholsonmalt · January 2, 2024, 7:05pm

Totally anecdotal but the sync client has always felt sluggish. Then again, so does OneDrive. The move to file transfers over HTTP was a big breakthrough in many ways but performance was not one of them. I assume HTTP/2 was devised to overcome this?

tflidd · January 5, 2024, 10:37am

When the client uploads chunks, which it does for large files (don’t remember if the default is still 10MB), it needs to track the chunks and the files currently being uploaded. Not sure if it uses a cache (with potential fallback to sqlite3) or if there is no deeper interaction (just on a FS level).

valix · March 3, 2024, 7:59am

I had similar problems. My Windows NC client was uploading at 7.7 to 8.1 Mbps (as if pinned down), even though the NC server has 1 Gbps bandwidth, but not the same network, 1 hop away. Sometimes the speed went up to 200 Mbps for a short time for no reason, less than 15 seconds. But there was never a speed problem with the web client.

I recorded the traffic and saw in Wireshark that the main cause is the uploading PC, not the server. No problems with window size, SACK, packetloss delays on the server side, but the client took up to 20 ms (!) to send the next 16kbytes (the remaining receive window of the server was still a bit over 2 Mbytes).

After reading some posts, I came up with the idea of setting a fixed bandwidth limit in the nc client. Until then it was not set.

And since then I get the bandwidth I set. Currently I set 40960 get about 325 Mbps ppload througput and no longer sees anything like 8 Mbps as nailed down.

robnicholsonmalt · March 4, 2024, 11:21am

Very interesting although that doesn’t make a lot of sense!