-
-
Notifications
You must be signed in to change notification settings - Fork 659
Performance
All credits for detailed performance testing goes to Michael Stiemke.
The following table shows the typical transfer speeds on various different Client CPUs, using both sync and async FTP clients.
FluentFTP Class | Application | Download speed | Upload speed | Client CPU |
---|---|---|---|---|
⚡ FtpClient | 🖱️ WinForms | 111 MB/sec | 80 MB/sec | Intel Core i9-13900K |
☁️ AsyncFtpClient | 🖱️ WinForms | 111 MB/sec | 80 MB/sec | Intel Core i9-13900K |
⚡ FtpClient | 🖥️ Console | 111 MB/sec | 80 MB/sec | Intel Core i9-13900K |
☁️ AsyncFtpClient | 🖥️ Console | 60 MB/sec | 80 MB/sec | Intel Core i9-13900K |
⚡ FtpClient | 🖱️ WinForms | 111 MB/sec | 80 MB/sec | Intel Core i7-6700HQ |
☁️ AsyncFtpClient | 🖱️ WinForms | 80 MB/sec | 80 MB/sec | Intel Core i7-6700HQ |
⚡ FtpClient | 🖥️ Console | 111 MB/sec | 80 MB/sec | Intel Core i7-6700HQ |
☁️ AsyncFtpClient | 🖥️ Console | 60 MB/sec | 80 MB/sec | Intel Core i7-6700HQ |
These are the test conditions that were used to measure the file transfer speed.
- Network
- Network transfer rate: 1Gb/s
- File
- File size: 1GB
- File contents: Random bytes
- Server
- Server CPU: Core I9-10900K
- Server Hard Disk: 1500MB/s SSD
- Server Operating System: Debian 11
- Server FTP Software: ProFTPd
- Client
- Client CPU: Mentioned in the table above
- Client Operating System: Windows 10
- Client Hard Disk: 1500MB/s SSD
- .NET Build type: Release build
- .NET version: .NET 6
- .NET application: WinForms or Console Application
- Library version: FluentFTP V50.0.1
- Stream type: SslStream, in-built in FluentFTP (Performance of FluentFTP.GnuTLS was equivalent in all cases)
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.
The server must of course be able to supply or ingest data fast enough fully utilize the available network resources.
The client must also not be hampered by a slow or busy CPU whilst the IO performance will seriously slow down transfers.
The newer the version of .NET that you target, the better your results will be. The differences in CPU usage between older .NET Framework versions and .NET 6, for example, can be very significant, especially when using async methods. Your file transfer can easily become CPU bound and thus your transfer times will scale to your CPU and not your network.
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. You can't get much better than that.
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.
- Auto Connection
- Auto Reconnection
- FTP(S) Connection
- FTP(S) Connection using GnuTLS
- FTPS Proxies
- Custom Servers
- Custom Commands
- v40 Migration Guide