Small files crawl over VPN because of round trips, not speed

Copy one 2 GB file over the VPN and the transfer looks fine. Copy a folder of ten thousand small documents and the same link seems broken. The difference is not a bandwidth setting that changed between the two jobs. The second job spends its time on setup, metadata, and waiting for answers, and the tunnel's latency is what makes that waiting visible.

One file streams; a folder of files negotiates

A large copy spends most of its life in a read-write loop on a small number of open handles. The protocol overhead is paid once per file, and the data moves in large blocks. Bandwidth dominates the result.

A folder copy pays per file: create, query attributes, open, write, close, and update directory metadata. Each of those is a request that waits for a response before the next step can proceed. The bytes are tiny; the coordination is not.

That is why a low link-utilization graph proves almost nothing. The link is idle because the client is waiting, not because the tunnel is slow. A storage array or an endpoint scanner can add the same shape of delay. Identify which stage is waiting before changing any network setting.

Round trips add up faster than bytes

Latency is the cost of one dependent exchange. If a file needs several serialized exchanges and the tunnel adds 40 ms each way, the per-file cost grows quickly. Ten thousand files turn that into minutes.

The arithmetic is illustrative, not a benchmark: a file is not guaranteed to cost one round trip, and clients overlap some work.

Two levers change the total. Reduce the number of dependent exchanges per file, or keep more of them in flight at once. The first is a protocol or workload change; the second is concurrency. Neither makes a slow link faster.

Measure the workload, not the link

Compare three jobs with the same endpoints and access policy: one large file, the small-file folder, and the actual business operation. Record file count, size distribution, copy tool, and network conditions with each result.

A single MB/s number without those details cannot be compared with anyone else's.

Measure latency separately from throughput. A simple round-trip test to the file server gives the number that multiplies across small operations. Then watch the copy's request pattern rather than its average rate. If the rate is low and the link is idle, the bottleneck is above the tunnel.

Change the job: concurrency and archives

For an authorized bulk copy, a tool with controlled concurrency keeps more requests in flight. Robocopy's /MT option is the common Windows example. Adding threads does not guarantee a faster copy.

Pick a count the client, the server, and the storage can sustain, and keep the job log and any errors.

Archiving at the source and unpacking locally removes per-file remote work. Include preparation and extraction time in the comparison, and confirm the archive preserves the metadata and permissions the task needs. Neither trick makes an application batch its own file operations.

Check the counter with a controlled test

Run the same job twice with one variable changed, and record both numbers. A controlled test is the only way to know whether a setting helped or the network happened to be quieter.

Two commands give the file count and the round-trip baseline:

Get-ChildItem \\fileserver.hq.example\\share -Recurse | Measure-Object -Property Length -Sum
ping -n 20 fileserver.hq.example

Then run the copy with a bounded thread count and compare the log against the previous run:

robocopy \\fileserver.hq.example\\share C:\\local /E /MT:16 /LOG:copy.log /TEE

Do not disable SMB signing, encryption, or endpoint protection to improve the counter. Those changes trade a security property for a number that may not have been the bottleneck. And keep the VPN transport separate from SMB's own transport in your notes, because a fix in one is not evidence about the other.