Speed and large files

🐢 Speed and large files

A mapped drive and a synced folder look the same in Explorer and behave nothing alike. Most reports of NcDavTray is slow with big files are that difference, and this page shows how to tell it apart from a connection that really is too slow.

Tip

TL;DR — A drive has no local copy. Opening a 70 MB file means fetching 70 MB, and saving it means sending 70 MB back, every time. The Nextcloud desktop client opens a file that is already on your disk, which is why it feels instant. Measure your throughput with the snippets below before assuming something is broken.

• What a mapped drive does differently
• The limits that stop a file outright
• Measuring it yourself
• Reading the numbers
• What actually helps

🔀 What a mapped drive does differently

	Nextcloud desktop client	Mapped drive
Where the file is	on your disk, kept in step with the server	on the server only
Opening it	a local read, no network involved	the content is fetched first, every time
Saving it	writes locally, uploads in the background	the file goes back over the network before the application is done
Large files	cost disk space, not waiting time	cost waiting time on every open and every save
Files you never touch	still occupy disk space	cost nothing

Neither is better. They answer different questions, and nothing stops you from using both on the same machine: the desktop client for the folders with the heavy files, a drive for everything else.

Windows does keep a cache of what it fetched, see WebDAV cache, but a cache is not a synced copy. Nothing guarantees a file is still in it the next time you open it, and it is shared by every WebDAV drive on the machine.

Note

An Office file is a container holding many parts, and an application does not necessarily read it from beginning to end. That is why a big spreadsheet or presentation can feel slower than a video of the same size: the transfer time is the same, the number of round trips is not, and every round trip costs the latency to your server once more.

🚧 The limits that stop a file outright

A file that refuses to open at all, rather than opening slowly, has usually hit one of the redirector's limits. They are all in Settings, WebClient tuning, and they belong to Windows rather than to NcDavTray, so they apply to every WebDAV drive on the machine. See WebClient service for the full list.

Symptom	The setting
Files above roughly 50 MB fail while smaller ones work	Maximum file size, FileSizeLimitInBytes. The Windows default is 50,000,000 bytes and it can be raised to 4 GB
A transfer starts and then aborts partway	Send / receive timeout. It limits how long one transfer may stall, and a slow link can run into it
A folder with very many files behaves erratically	Maximum files per folder

📏 Measuring it yourself

Three measurements answer the question. Run them in a normal PowerShell window, no administrator rights needed.

Latency to your server. How long a single connection takes to set up. This is what every round trip costs, and it is often what makes an Office file feel slow rather than the bandwidth.

1..3 | ForEach-Object {
	$sw = [Diagnostics.Stopwatch]::StartNew()
	$c  = [Net.Sockets.TcpClient]::new()
	$c.Connect('cloud.example.com', 443)
	$sw.Stop(); $c.Close()
	'{0} ms' -f $sw.ElapsedMilliseconds
}

Download throughput from the drive. Pick a file that is big enough to measure, ideally the one that is giving you trouble.

$file = 'Z:\path\to\your\file.pptx'
$size = (Get-Item $file).Length
$t = Measure-Command { Copy-Item $file $env:TEMP -Force }
'{0:N1} MB in {1:N1} s = {2:N2} MB/s' -f ($size/1MB), $t.TotalSeconds, ($size/1MB/$t.TotalSeconds)
Remove-Item (Join-Path $env:TEMP (Split-Path $file -Leaf)) -Force

Upload throughput to the drive, which is what saving costs. This one writes to your Nextcloud and removes the file again, so run it in a folder where a temporary file does no harm.

$target = 'Z:\speedtest.tmp'
$bytes  = New-Object byte[] (20MB)
[Security.Cryptography.RandomNumberGenerator]::Create().GetBytes($bytes)
$local  = Join-Path $env:TEMP 'speedtest.tmp'
[IO.File]::WriteAllBytes($local, $bytes)
$t = Measure-Command { Copy-Item $local $target -Force }
'{0:N1} MB in {1:N1} s = {2:N2} MB/s' -f (20MB/1MB), $t.TotalSeconds, (20MB/1MB/$t.TotalSeconds)
Remove-Item $target, $local -Force

Tip

Random bytes on purpose: they do not compress, so nothing along the way can flatter the result.

Run each of them twice. The first run of a download can be faster than the truth if the content is still in the cache, and slower than the truth if the connection was idle.

🧮 Reading the numbers

Divide the file size by the throughput you measured, and you have what a single open costs. A save costs the same again in the other direction.

Your throughput	A 70 MB file takes about
0.5 MB/s	2 minutes 20 seconds
1 MB/s	1 minute 10 seconds
5 MB/s	14 seconds
20 MB/s	4 seconds

If your measured time roughly matches that table, the drive is doing what a drive does, and nothing in the settings will change it. What helps is below.

If opening the file takes much longer than the table says, the transfer is not the bottleneck. Latency in the hundreds of milliseconds is the usual reason, and the Diagnostics report is the next step: it collects the redirector settings, the WebClient event log and the state of your mounts in one file.

Note

Comparing against the desktop client is not a fair test in either direction. Opening a synced file measures your disk, not your connection. What the client can tell you is whether a full download of the same file takes about as long as your drive measurement, since it is the same content over the same line.

🛠️ What actually helps

Copy, work, copy back. For a file you will save a dozen times, copy it to a local folder, work there, and copy it back once. That is two transfers instead of two dozen.

Use the desktop client for the heavy folders. It downloads once in the background and everything after that is local. Keep NcDavTray for the folders you browse rather than edit, which is what a drive is good at.

Raise the file size limit before you need it. Maximum file size in WebClient service costs nothing to raise and turns a hard failure into a slow success.

Do not expect the cache to help. It is a cache belonging to Windows, not a copy belonging to you. See WebDAV cache.