Performance

What aspects influence FTP file transfer speed?

1. Network speed/latency

While the influence of network transfer speed is a major factor in the performance of large data transfers, the transfer of very many small files will profit also from overall network latency and round-trip times, as the command-response sequences on the control connection become a bottleneck.

2. Server CPU / IO performance

The server must of course be able to supply or ingest data fast enough fully utilize the available network resources.

3. Client CPU / IO performance

The client must also not be hampered by a slow or busy CPU whilst the IO performance will seriously slow down transfers.

Does FTP slow down file transfer?

No, FTP(S) was designed to have virtually no protocol overhead on the data transfer itself. No overhead, that is, other than that imposed by Ethernet, as well as IP and TCP.

Wired Ethernet will be the fastest transport for file transfer and should be preferred in all cases.

WiFi will be significantly slower than Wired Ethernet. But this will not be due to any "flaws" in the actual FTP(S) protocol. Even the CPU-bound calculations needed for encryption/decryption are so fast on modern CPUs.

What is the theoretical maximum file transfer speed?

Theoretical maximum transfer rate on a 1Gb/s ethernet connection, taking all ethernet frame headers into account would be 118MB/sec (even 123MB/s using jumbo frames = 99% of 1Gb/s).

Now take into account IP / TCP headers, which can be minimised by avoiding fragmentation, using jumbo packets, avoiding resends, delaying ACKs and other measures. This can be estimated at about 2.8% of the available bandwidth, so we arrive at a speed of about 114MB/sec.

What are the typical file transfer speeds I can expect?

Test conditions

These are the test conditions that were used to measure the file transfer speed.

• Network transfer rate: 1Gb/s
• Server side CPU is one core of a Core I9-10900K writing to / reading from a 1500MB/s SSD.
• Client side, unless otherwise stated is Windows 10, Core I9-13900K client side, writing to / reading from a 1500MB/s SSD.
• Server is proFTPd on Debian 11.
• Downloading a 1GB file filled with random bytes.
• Winforms or Console Application using FluentFTP V50+
• SslStream (Performance of FluentFTP.GnuTLS was equivalent in all cases)
• All supported .NET versions

FtpClient (WinForms)

• Download speed was about 111 MB/s
• Download duration was about 9 seconds
• This speed is close to the theoretical max.

AsyncFtpClient (WinForms, Core I9-13900K client side)

• Download speed was about 111 MB/s
• Download duration was about 9 seconds
• This speed is close to the theoretical max.

AsyncFtpClient (WinForms, Core I7-6700HQ client side)

• Download speed was about 73 MB/s
• Download duration was about 14 seconds
• This speed is close to the theoretical max.

FtpClient (Console Application)

• Download speed was about 111 MB/s
• Download duration was about 9.01 seconds
• This speed is close to the theoretical max.

AsyncFtpClient (Console Application), Core I7-6700HQ client side)

• Download speed was about 20 MB/s
• Download duration was about 50 seconds

AsyncFtpClient (Console Application, Core I9-13900K client side)

• Download speed was about 70 MB/s
• Download duration was about 50 seconds

Why do Async and Console apps show poor file transfer speeds?

1. The transfer speed was heavily dependent on client side CPU performance. Async state machine handling does incur some CPU overhead that can be visible on less powerful clients.
2. The tests were run in Visual Studio in "Debug" configuration. Once the tests were built and run in "Release" configuration, the transfers speeds were significantly improved - probably due to optimisation being disabled in Debug builds.