Sftp And Ftp Client For Mac
So, you have files you need to manage on servers. Maybe you’re a developer. Maybe you’re a system administrator. Maybe you’re a contractor or freelancer. But you need to connect to a thing, and upload, download, or tweak the files on that thing.
That’s what Transmit is for.
SFTP Client is a Google Chrome Webstore application, for use with your Google Chrome Web Browser, Chrome OS / Chromebook. SFTP Client can be used to connect to your FTP / SFTP or SSH server, transfer files, edit files, changes file permissions and much more. The client is very secure with Secure FTP (FTPS) using SSL/TLS, New SSH File Transfer Protocol (SFTP). S/Key password encryption, application password protection, SSL Site-to-Site (SSCN) transfers and Clear Command Channel (CCC) support for SSL/TLS FTP connections.
Transmit’s big strength is its clean interface — our famous “dual-pane” view is way faster than the Finder. But Transmit also has tons of very nice features like File Sync, which can mirror remote and local (or, now, local and local!) files in one click.
Transmit also takes great care to let you organize your Servers for fast access. And with Panic Sync, you can sync them to all of your computers. Never type a server address again.
Now, long ago we’d call Transmit an “FTP client”, but today, with Transmit 5, we connect to lots of different server types and cloud services. For example, Amazon S3 dramatically changed the way files are served on the internet, and Transmit is a great way to manage your Amazon S3 buckets.
Put simply: Transmit lets you quickly and easily manage files on the internet.
A few months ago we decided to run a comprehensive speed test of the best file transfer clients for macOS. During this process, we made some observations which allowed us to increase the file transfer speed of ForkLift even more. In this blog post, we’ll tell you what changes we’ve made to make ForkLift faster, and we’ll reveal the results of our speed test.
ForkLift is a file manager and a file transfer tool for Mac supporting a wide variety of file transfer protocols. With ForkLift – among many other things – you can copy, move or delete files on your Mac locally and you can also connect to remote servers to upload, download or delete files. A lot of people have to connect to remote servers or cloud storages to transfer files on a daily basis, for example:
- Web developers
- Web designers
- System administrators to move files to and from servers and even edit them remotely
- Photographers to back up their photos to Amazon S3 or other providers
- Bloggers to upload files to WordPress or other platforms
- Everyday users who back up or store data on a NAS (Network Attached Storage), Google Drive or Dropbox
Nobody wants to spend too much time moving files from one place to another. This is especially true when the actual work can only begin after the files have been transferred. That’s why performance is one of the most important factors of file transfer apps.
Why we compared the best file transfer clients
Because it’s important how fast you can transfer files, we have always monitored ForkLift’s uploading and downloading capabilities, but we hadn’t conducted a comprehensive speed test comparing ForkLift to several other top file transfer clients. We knew that some of our competitors were also paying a lot of attention to the upload and download speed of their apps. Some of them even claimed to be the fastest file transfer client on the market. We wanted to find out how fast these file transfer clients actually were and where ForkLift ranked among them.
What started out as a comprehensive speed test, turned into a series of revisiting and rewriting of some of the file transfer frameworks we use in ForkLift. Thanks to these changes, ForkLift has become an even faster file transfer tool.
In the next few paragraphs I’ll explain what and why we have changed during the testing process. If you want to go straight to the speed test, just click here.
Transferring files
Before I tell you how one file transfer client can be faster than the other, let me explain how transferring files works. You might better understand the process by imagining it like eating at a restaurant. Eating at a restaurant has its rules, just as the different file transfer protocols have their own rules. In a restaurant, you take a seat, wait for the waiter, order a drink, go over the menu and then you order your meal. When you have finished your meal, you have to wait for the waiter to clear the table and then you can ask for the bill, and you can only leave after you have paid. Transferring the file equals the consumption of the food, everything before and after the meal is what we call the overhead. In the case of the file transfer, the overhead is the indirect computation and communication time that is required to perform the file transfer. It takes time to build up, to handle and to end the communication with the remote server just as ordering and paying at the restaurant take time.
Transferring small files is like ordering peas one by one at the restaurant. You have to make the same routine as described above but all you will get at a time is a single pea. Because the pea is so small, you can eat it very fast, but if you want to eat more peas, first you have to pay for the first pea and only after that can you order a new one. When you are transferring small files, the transferring itself takes almost no time, just as eating a pea, but the computation and communication time is the same as with big files. The time spent with “everything else” compared to the time spent with the actual transfer is too big, the overhead becomes significant. But luckily, we can solve this problem. You can finish your meal faster if more than just one waiter is serving you. That way you don’t have to wait for the waiter to return from the kitchen because there are more waiters attending to you simultaneously. Sending in more waiters to serve you is like opening new threads to transfer files. Multiple threads can transfer files simultaneously just as multiple waiters can serve you simultaneously.
When you use more threads, you can transfer more data at the same time, and your transfer becomes quicker. That’s why multithreading can have a big impact on the transfer speed and time. The difference in transfer time gets even more significant when you are transferring a lot of small files.
Because we at Binarynights have always paid a lot of attention to the upload speed, Forklift has handled file transfers multi-threaded ever since it first came out in 2007. The way how the multi-threaded file transfer was implemented in ForkLift made it already very fast and one of the fastest clients, but there was still some room for improvement. During our tests, we found ways to make the file transfers with ForkLift via SFTP (SSH File Transfer Protocol) and Amazon S3 (Amazon Simple Storage Service) even faster, and we also changed the way how ForkLift was deleting files.
Improving multithreading in our SFTP Client
During testing the SFTP transfers, we noticed that even though ForkLift would have been able to upload faster, the CPU on the server-side became a bottleneck limiting the upload performance and increasing the upload time. Keeping the example of the restaurant, this meant that there were several waiters trying to attend to you at the restaurant, but they could only use a single door to enter and exit the kitchen. They were standing in each other’s way and weren’t able to serve you as fast as they could have. ForkLift was trying to open multiple threads but because of the way how the software on the server-side works the server handled these threads as a single thread. The server-side only used one CPU to manage the threads and it reached its limits. In our test, out of the four CPUs available, only one CPU was handling the requests running at 100% while the other three CPUs weren’t involved in the upload process.Theoretically, all four CPUs should have taken part in the process to speed up the file transfer, but because of the implementation of the protocol on the server-side, this wasn’t happening. Realizing this, we’ve made some changes to the way how ForkLift was managing SFTP connections. Now, when we want ForkLift to open a new thread via SFTP, we force it to open a new connection. Making new connections is like opening more doors between the dining room and the kitchen of the restaurant so that the waiters don’t have to use the same door anymore to enter and exit. With this modification, we force the server to use multithreading the way it is supposed to. With this change, ForkLift uses the resources of the server more efficiently making the file transfer via SFTP faster.
A faster Amazon S3 Client with S3 multipart upload
We’ve also made some big changes to our Amazon S3 transfer tool. First of all, we’ve completely rewritten the Amazon S3 framework we used before. The main reason for writing our own Amazon S3 framework was that we wanted to enable connections to other Amazon S3 based cloud storage services as well. Before, you could only connect to s3.amazonaws.com: Amazon’s own cloud storage service. But there are more and more online storage service providers, which have implemented the Amazon S3 protocol. Wasabi and DigitalOcean are two notable S3-compatible cloud storage providers. With Forklift, from now on you can connect to Wasabi and DigitalOcean and any cloud storage provider which uses the Amazon S3 protocol.
Alone the rewriting of the framework made ForkLift faster than before, but we’ve gone one step further. To make transferring files even faster, we have also implemented the S3 multipart upload of big files.
When you connect to your Amazon S3 storage, the throughput of that connection is limited by Amazon. When you are uploading big files, this limitation can make your upload time significantly longer. But with the multipart upload of big files, Amazon also offers a way around this limitation. During the multipart upload, the large files are split into multiple parts, and these parts get uploaded using more connections in parallel. The throughput of each connection is limited, but when we open more connections, we can increase the combined throughput significantly. After all the parts have been uploaded using the multiple connections, the large file gets reconstructed from the parts. This way, the file can be uploaded much faster. With these implementations ForkLift uses the given means and resources more efficiently making the upload of big files faster.
In our speed test, we compared the big file upload performances of the tested Amazon S3 tools by uploading a 1 GB file to an Amazon S3 Bucket.
The implementation of the multipart upload has made the upload of the 1 GB file with ForkLift more than twice as fast as before, reducing the upload time from 92 seconds to just 40 seconds. According to our Amazon S3 tests, the implementation of the S3 multipart upload in ForkLift can make uploads of big files even up to 5 times as fast as before.
Deleting files on remote servers
ForkLift was the fastest file transfer client to delete files in almost all of the tested scenarios even during our initial testing. The reason for this is that ForkLift uses multiple threads not only to upload and download but also to delete files. Even though ForkLift was already the fastest client to delete files on remote servers except for one tested scenario, we’ve made some changes to it to make deletions even faster.
Deleting files is a simpler process than uploading or downloading. When you are deleting, the size of the file doesn’t influence how long the process takes. Deleting a huge file doesn’t take longer than deleting a small file. In previous versions of ForkLift when you hit delete, ForkLift first started to calculate how much time it would take to delete the files. That was necessary to generate the progress bar so you could follow the deletion process in the activity display. In a lot of cases, the time you had to wait just for this information was longer than the deletion part which followed the calculation. Because of this, we have decided to start the computation and the deletion at the same time. As a result, deleting files got even faster. Now, in most situations, the deletion process takes around the same amount of time as the calculation alone took in previous versions. The only drawback of this method is that in most cases ForkLift deletes the files so quickly that there is no time to generate the progress bar. When the deletion part takes longer than the computation part, the progress bar will be generated during the deleting process. We’ve opted for an even faster deletion rather than the progress bar.
Now, that you know all about what and why we have changed in ForkLift during the testing process, let’s see how well the different file transfer tools performed on our test.
Looking for the fastest FTP tool
In our test we compared the latest versions of five advanced file transfer clients for macOS:
- Cyberduck 6.6.2
- FileZilla Pro 3.34.0
- ForkLift 3.2.3
- Transmit 5.1.4
- Yummy FTP Pro 2.0.5
File transfer clients are often called FTP clients even though the most established file transfer tools support a much wider variety of protocols than just FTP. Maybe because of its name (File Transfer Protocol), a lot of people still associate file transfer with FTP and call file transfer tools FTP tools. Out of the ten protocols supported by ForkLift we’ve tested these four protocols:
- FTP and SFTP because these two are still the most used protocols and
- Amazon S3 and WebDAV HTTPS because these are becoming more and more popular
We tested five tasks with every tool using each protocol. We:
- uploaded a big file (1 or 5 GB depending on the protocol)
- downloaded a big file (1 or 5 GB depending on the protocol)
- uploaded 16471 small files (with a combined size of 264.8 MB)
- downloaded 16471 small files (with a combined size of 264.8 MB)
- deleted 16471 smallfiles (with a combined size of 264.8 MB)
We repeated each task 3 times with each tool and compared the best times between them.
Testing environment
To conduct our tests we used the following testing environment:
- MacBook Pro 2016 15″ with Touch Bar running macOS 10.13.5
- Satechi USB-C Adapter with Gigabit Ethernet port
- Server: Synology DS1517+ with four Samsung 850 Evo Basic 2TB SSDs in RAID10 and Synology E10G17-F2 10 GbE SFP+ Adapter
- Switch: Netgear ProSafe XS708T connected to Synology NAS via SFP+ cables
At the beginning of our testing process, we spent a lot of time figuring out how we should set up the most objective testing environment to guarantee the same conditions for every tool and to give them the same chance to perform at their absolute best.
To test FTP, SFTP and WebDAV over HTTPS we used our own local area network. There were no other processes running at the same time using and taking away bandwidth. We restarted the Synology NAS regularly to delete the cache. Since the Amazon S3 protocol can only be tested over the internet, we needed to find the off-peak time periods during which the Amazon S3 server/network usage was low. We tested every Amazon S3 tool in the same off-peak time period, late at night. We connected to an Amazon S3 Bucket in the Frankfurt Region because that region is the closest to our office.
Client setup
We tried to use the same setup in each tool. Since ForkLift uses five simultaneous transfers at the same time as default, this was what we tried to use in all other transfer clients too. In Cyberduck you can’t change the number of the simultaneous transfers, so we had to stick to its default settings. In FileZilla, we raised the number of simultaneous file transfers from the default two to five but FileZilla wasn’t able to operate well like that at all. When we used five or four simultaneous transfers at the same time in FileZilla, the file transfers kept getting interrupted or the app froze or crashed. We figured out that the highest number of simultaneous transfers FileZilla could handle was three, so we used that setting during our tests.
The best FTP clients for Mac compared
The most balanced results of the entire series of tests came from uploading and downloading the 5 GB file via FTP.
Best Ftp Client For Mac
There was almost no difference between the upload and download times using FTP. Four out of the five clients needed the same amount of time to finish, and the remaining fifth client finished 1 second later in both scenarios. All the clients delivered basically the same performance transferring the big file.
On the other hand, we observed big differences between the FTP clients when we were working with small files.
Uploading the 16471 small files took both ForkLift and Yummy FTP 14 seconds and Cyberduck 16 seconds. The fastest clients (ForkLift and Yummy FTP) were uploading 1.86 times as fast as Transmit, the third and 4.64 times as fast as Filezilla, the slowest FTP client.
ForkLift was the fastest to download the same small files, it finished the task within 16 seconds and Yummy FTP, which came in second, was short by just 2 seconds. ForkLift downloaded the files 2.67 times as fast as Transmit, the third fastest and 5.63 times as fast as FileZilla, the slowest one.
ForkLift was also the fastest FTP client to delete the small files. ForkLift needed 13 seconds to finish the deletion which is almost half the execution time of Transmit, the second and almost third the execution time of FileZilla, the slowest FTP app.
When we add up the times which were required to complete all five operations, we see that ForkLift was the fastest FTP client in our test finishing in 2 minutes and 10 seconds.
| FTP | ForkLift 3.2.3 | Yummy FTP Pro 2.0.5 | Transmit 5.1.4 | Cyberduck 6.6.2 | FileZilla Pro 3.34.0 |
|---|---|---|---|---|---|
| Combined time | 2m 10s | 2m 28s | 3m 1s | 3m 32s | 4m 40s |
| Comb. time ratio | 1.00 | 1.14 | 1.39 | 1.63 | 2.15 |
We compared the combined execution times of each software to the combined execution time of the fastest tool. Because ForkLift was the fastest to finish all five tasks using FTP, its time ratio is 1.00. ForkLift was 1.14 times as fast as Yummy FTP, the second and 1.39 times as fast as Transmit, the third and more than twice as fast as FileZilla, the slowest FTP software in this test.
Show/Hide Table of FTP Comparison| FTP | ||||||
|---|---|---|---|---|---|---|
| File Operation | Test | ForkLift 3.2.3 | Transmit 5.1.4 | Cyberduck 6.6.2 | FileZilla Pro 3.34.0 | Yummy FTP Pro 2.0.5 |
| Upload (5GB file) | #1 | 0m 44s | 0m 45s | 0m 44s | 0m 45s | 0m 44s |
| #2 | 0m 44s | 0m 45s | 0m 44s | 0m 45s | 0m 45s | |
| #3 | 0m 45s | 0m 44s | 0m 44s | 0m 46s | 0m 45s | |
| Best | 44s | 44s | 44s | 45s | 44s | |
| Download (5GB file) | #1 | 0m 43s | 0m 44s | 0m 43s | 0m 43s | 0m 44s |
| #2 | 0m 43s | 0m 44s | 0m 43s | 0m 43s | 0m 43s | |
| #3 | 0m 44s | 0m 44s | 0m 43s | 0m 43s | 0m 43s | |
| Best | 43s | 44s | 43s | 43s | 43s | |
| Upload (16471 items – 264,8MB) | #1 | 0m 14s | 0m 27s | 0m 16s | 1m 10s | 0m 14s |
| #2 | 0m 15s | 0m 26s | 0m 18s | 1m 5s | 0m 16s | |
| #3 | 0m 14s | 0m 27s | 0m 16s | 1m 11s | 0m 14s | |
| Best | 14s | 26s | 16s | 65s | 14s | |
| Download (16471 items – 264,8MB) | #1 | 0m 16s | 0m 48s | 1m 31s | 1m 33s | 0m 20s |
| #2 | 0m 17s | 0m 48s | 1m 24s | 1m 30s | 0m 18s | |
| #3 | 0m 17s | 0m 43s | 1m 27s | 1m 31s | 0m 18s | |
| Best | 16s | 43s | 84s | 90s | 18s | |
| Delete (16471 items – 264,8MB) | #1 | 0m 15s | 0m 27s | 0m 28s | 0m 37s | 0m 29s |
| #2 | 0m 13s | 0m 24s | 0m 25s | 0m 38s | 0m 30s | |
| #3 | 0m 13s | 0m 25s | 0m 26s | 0m 38s | 0m 30s | |
| Best | 13s | 24s | 25s | 37s | 29s | |
The best SFTP clients for Mac compared
Comparing the SFTP clients uploading and downloading a big file, delivered similar results compared to the test of the FTP clients with one exception.
Using SFTP, there was also almost no difference between four out of the five clients but this time the transfer times of the slowest client weren’t close to the results of the other four apps. We observed the exact opposite of that, Cyberduck needed up to 6 times longer than the other clients to perform the tasks of uploading and downloading the five GB file.
Even though the results of the other four clients were close to each other, when it came to the upload of the big file, Filezilla was in the lead compared to the other transfer clients. Filezilla was 38% faster than the other three clients.
This advantage disappeared when it came to the download of the big file: all four clients downloaded the big file in either 68 or 69 seconds.
When we take a look at the performance of the SFTP softwares when handling small files, we can see that the results vary.
ForkLift finished uploading, downloading and deleting the small files within 14 seconds in each test, meaning it was ahead of all the other SFTP clients in all three scenarios.
ForkLift finished the upload 1.43 times as fast as Yummy FTP, the second fastest client, 1.86 times as fast as Transmit, the third and 3.29 times as fast as Cyberduck, the fourth. FileZilla, the slowest SFTP app in the test, took 10.71 times as long to upload the files as ForkLift, meaning that it needed 150 seconds instead of 14.
When it came to the download of the 16471 small files, ForkLift was almost twice as fast as Yummy FTP, the second fastest and 3.5 times as fast as Transmit, the third fastest. ForkLift was more than 16 times as fast as FileZilla, the slowest tool.
ForkLift needed 14 seconds to delete all the small files and Transmit and Cyberduck, which shared the second place, needed 34 seconds each. That made ForkLift 2.43 times as fast as Transmit and Cyberduck. ForkLift was 3.5 times as fast as Cyberduck and 5.43 times as fast as FileZilla, which finished last.
The clear winner of the SFTP client speed test was ForkLift, but we also have to point out that in some cases the absolute differences between the clients were very small. For example in the case of the upload of the small files, the relative difference between the fastest and the second fastest client was more than 40%, but the absolute difference was only 6 seconds. On the other hand, these smaller differences can add up quickly which becomes pretty obvious when we take a look at the combined execution times of the SFTP tools in our test.
| SFTP | ForkLift 3.2.3 | Yummy FTP Pro 2.0.5 | Transmit 5.1.4 | FileZilla Pro 3.34.0 | Cyberduck 6.6.2 |
|---|---|---|---|---|---|
| Combined time | 3m 8s | 4m 0s | 4m 14s | 9m 38s | 15m 5s |
| Comb. time ratio | 1.00 | 1.28 | 1.35 | 3.07 | 4.81 |
To perform the same tasks, Yummy FTP, the second, needed 1.28 times as much time as ForkLift, the fastest SFTP tool and in third place, Transmit needed 1.35 times as much as ForkLift. Compared to the second and third fastest SFTP tools ForkLift shortened a 4 minutes long task by almost 1 minute. Because of the poor results of Filezilla uploading the small files and the poor results of Cyberduck uploading the big file, these two clients placed fourth and fifth respectively in the SFTP Speed Test. Filezilla needed 3 times as long as ForkLift and Cyberduck almost 5 times as long as ForkLift to perform all five tasks.
Show/Hide Table of SFTP Comparison| SFTP | ||||||
|---|---|---|---|---|---|---|
| File Operation | Test | ForkLift 3.2.3 | Transmit 5.1.4 | Cyberduck 6.6.2 | FileZilla Pro 3.34.0 | Yummy FTP Pro 2.0.5 |
| Upload (5GB file) | #1 | 1m 17s | 1m 17s | 5m 54s | 0m 56s | 1m 19s |
| #2 | 1m 17s | 1m 20s | 6m 22s | 0m 56s | 1m 17s | |
| #3 | 1m 18s | 1m 19s | 6m 11s | 0m 57s | 1m 18s | |
| Best | 77s | 77s | 354s | 56s | 77s | |
| Download (5GB file) | #1 | 1m 10s | 1m 11s | 6m 2s | 1m 12s | 1m 10s |
| #2 | 1m 9s | 1m 8s | 5m 56s | 1m 9s | 1m 8s | |
| #3 | 1m 9s | 1m 9s | 5m 59s | 1m 8s | 1m 9s | |
| Best | 69s | 68s | 356s | 68s | 68s | |
| Upload (16471 items – 264,8MB) | #1 | 0m 15s | 0m 27s | 0m 47s | 2m 31s | 0m 20s |
| #2 | 0m 14s | 0m 26s | 0m 46s | 2m 32s | 0m 20s | |
| #3 | 0m 15s | 0m 26s | 0m 47s | 2m 30s | 0m 21s | |
| Best | 14s | 26s | 46s | 150s | 20s | |
| Download (16471 items – 264,8MB) | #1 | 0m 14s | 0m 51s | 2m 1s | 3m 48s | 0m 26s |
| #2 | 0m 15s | 0m 49s | 1m 55s | 3m 49s | 0m 28s | |
| #3 | 0m 14s | 0m 50s | 1m 57s | 3m 48s | 0m 26s | |
| Best | 14s | 49s | 115s | 228s | 26s | |
| Delete (16471 items – 264,8MB) | #1 | 0m 14s | 0m 34s | 0m 35s | 1m 19s | 0m 49s |
| #2 | 0m 14s | 0m 34s | 0m 34s | 1m 16s | 0m 50s | |
| #3 | 0m 14s | 0m 35s | 0m 35s | 1m 17s | 0m 49s | |
| Best | 14s | 34s | 34s | 76s | 49s | |
The best WebDAV clients for Mac compared
As with the two previous protocols, using WebDAV HTTPS also delivered similar results when it comes to working with the big file.
Using WebDAV, ForkLift was the first to finish the upload of the 5 GB file, but Transmit and Filezilla were only 1 second slower, meaning there was no significant difference between them.
The same three clients (ForkLift, Transmit and Filezilla) were also the fastest to download the same file, needing the same amount of time (44 seconds) to finish. Cyberduck executed both tasks significantly slower, it needed more than double the time to finish.
Yummy FTP was also significantly slower uploading, but it only managed to download a part of the 5 GB file every time we tried to download the file (which was more than three times). Sadly, we don’t have any valid data to share about the big file download via WebDAV using Yummy FTP because the download process didn’t finish successfully.
As usual, working with multiple small files delivered more diverse results than working with a single big file also using WebDAV over HTTPS.
ForkLift was the fastest WebDAV client to upload the small files. ForkLift uploaded the files within 38 seconds, 1.26 times as fast as Transmit, the second fastest. Cyberduck and Yummy FTP took more than twice as much time as ForkLift to upload the small files and Filezilla took more than 7 times as much.
With the 27 seconds download time, ForkLift was the fastest WebDAV tool to download the 16471 small files. Transmit, which came in second also in this test, took double the time (55 seconds) to do the same. Cyberduck needed more than 5 times as long and Filezilla 7 times as long as ForkLift.
(The 69 seconds download time of Yummy FTP Pro in this scenario was measured using an earlier version of the software (version 2.0.3 instead of the latest version 2.0.5) because the latest version was downloading extremely slowly: the download took about an hour long. So instead of taking the latest data, we took the data of a previous test. We are sure that this problem will be solved in one of the upcoming updates of the software.)
Sftp For Mac
Cyberduck was the fastest to delete all the small files from the remote server via WebDAV HTTPS. Cyberduck outperformed all the other clients because it managed to delete the files within 5 seconds whereas ForkLift, the second fastest client, needed 90 seconds to do the same thing. This means that Cyberduck was 18 times as fast as the second fastest client and 30 times as fast as the slowest client in this test. Cyberduck has this big lead over the other tools because it supports server-side recursive deletion which the other tools don’t support at this moment.
Because of the issues we had encountered using Yummy FTP via WebDAV, we had to leave it out from the comparison of the combined times needed to perform all the tasks using WebDAV.
| WebDAV | ForkLift 3.2.3 | Transmit 5.1.4 | Cyberduck 6.6.2 | FileZilla Pro 3.34.0 |
|---|---|---|---|---|
| Combined time | 4m 05s | 5m 36s | 7m 9s | 11m 28s |
| Combined time ratio | 1.00 | 1.28 | 1.35 | 3.07 |
Out of the four clients which were able to finish all five tasks successfully, ForkLift was the fastest WebDAV client. ForkLift completed all tasks within 4 minutes and 5 seconds which made it 1.37 times as fast as Transmit, the second and 1.75 times as fast as Cyberduck, the third. By comparing the combined execution times of the fastest and the slowest WebDav clients, we see that using ForkLift instead of FileZilla saved 7 minutes and 23 seconds.
The best Amazon S3 clients for Mac compared
Since Yummy FTP doesn’t support the Amazon S3 protocol, we could only test four out of the five clients: ForkLift, Transmit, Cyberduck and FileZilla. During the Amazon S3 speed test, we transferred a 1 GB file as the big file.
ForkLift was the fastest Amazon S3 tool to upload the big file, it was 1.18 times as fast as Cyberduck, the second and 1.68 as fast as Transmit, the third. It took Filezilla almost 3 minutes to upload the file which was 4.48 times as long as the upload time of ForkLift.
There weren’t significant differences between the download times of the tools during the download of the 1 GB file via Amazon S3. ForkLift and Filezilla both downloaded the big file within 30 seconds finishing just 1 second before Transmit and 4 seconds before Cyberduck.
Testing the Amazon S3 browsers with small files, delivered very varied results. In each scenario, two out of the four clients finished in much less time than the other two.
It took ForkLift 3 minutes and 41 seconds (221 seconds) to upload the small files which was the best result in this test. Completing the same job took Transmit 27% more time. It took Cyberduck more than 12 minutes to upload the same files which is 3.39 as much time as it took ForkLift. Filezilla needed more than 34 minutes to upload the files which is 9.24 times as much as the upload time of ForkLift.
We can also see a similar outcome in the case of the download: ForkLift finished first and Transmit second. Transmit needed 41% more time than ForkLift to complete the download of the small files. Cyberduck and Filezilla also lagged behind ForkLift and Transmit this time by a large margin. Cyberduck, the slowest client in this test, needed 32 minutes and 33 seconds to download the files whereas ForkLift needed only 3 minutes and 27 seconds. That means that it took Cyberduck 9.43 times as long to complete the task as it took ForkLift.
On the other hand, Cyberduck was the first to delete the 16471 small files finishing 2 seconds before ForkLift. In this test Transmit was the slowest Amazon S3 app, it needed almost 5 times as much time to delete the small files as Cyberduck.
When we add up the times needed to perform all five tasks using the Amazon S3 protocol, we can see that ForkLift is the clear winner of the Amazon S3 Speed Test.
| Amazon S3 | ForkLift 3.2.3 | Transmit 5.1.4 | Cyberduck 6.6.2 | FileZilla Pro 3.34.0 |
|---|---|---|---|---|
| Combined time | 11m 49s | 28m 30s | 49m 52s | 66m 6s |
| Combined time ratio | 1.00 | 2.41 | 4.22 | 5.59 |
Even the second-placed Transmit needed 2.41 times as much time to finish the operations as ForkLift and Cyberduck more than 4 times as much. FileZilla, the slowest client in this test, took 5.59 times as long as ForkLift. That means that using ForkLift instead of FileZilla to complete these five tasks saved almost 55 minutes.
Show/Hide Table of Amazon S3 Comparison| Amazon S3 | |||||
|---|---|---|---|---|---|
| File Operation | Test | ForkLift 3.2.3 | Transmit 5.1.4 | Cyberduck 6.6.2 | FileZilla Pro 3.34.0 |
| Upload (1GB file) | #1 | 0m 49s | 1m 9s | 0m 49s | 3m 7s |
| #2 | 0m 48s | 1m 7s | 0m 50s | 3m 11s | |
| #3 | 0m 40s | 1m 16s | 0m 47s | 2m 59s | |
| Best | 40s | 67s | 47s | 179s | |
| Download (1GB file) | #1 | 0m 32s | 0m 32s | 0m 34s | 0m 31s |
| #2 | 0m 30s | 0m 31s | 0m 34s | 0m 30s | |
| #3 | 0m 33s | 0m 32s | 0m 36s | 0m 31s | |
| Best | 30s | 31s | 34s | 30s | |
| Upload (16471 items – 264,8MB) | #1 | 3m 52s | 4m 42s | 12m 29s | 89m 18s |
| #2 | 3m 41s | 4m 40s | 12m 36s | 34m 3s | |
| #3 | 3m 43s | 4m 41s | 12m 39s | 37m 19s | |
| Best | 221s | 280s | 749s | 2043s | |
| Download (16471 items – 264,8MB) | #1 | 4m 43s | 5m 8s | 32m 33s | 19m 6s |
| #2 | 3m 27s | 5m 9s | 32m 38s | 20m 26s | |
| #3 | 3m 28s | 4m 51s | 32m 36s | 19m 57s | |
| Best | 207s | 291s | 1953s | 1146s | |
| Delete (16471 items – 264,8MB) | #1 | 3m 32s | 17m 44s | 3m 38s | 9m 38s |
| #2 | 3m 31s | 18m 11s | 3m 29s | 9m 28s | |
| #3 | 3m 33s | 17m 21s | 3m 32s | 9m 32s | |
| Best | 211s | 1041s | 209s | 568s | |
Sftp Client And Ftp Client For Mac
Conclusion of the Speed Test
ForkLift was the fastest client in 80% of all scenarios, finishing 16 times on top. Because in some cases some of the file transfer clients shared the best times or were close to each other, we didn’t only count the number of top finishes but also compared the combined execution times of the clients with each other. That way we got a clearer picture of the overall performances of the tools.
ForkLift wasn’t only the fastest client to complete all twenty tasks in our test but it also finished on top using each protocol. ForkLift was the fastest FTP, the fastest SFTP, the fastest WebDAV and even the fastest Amazon S3 client. When we compare the combined execution times which were needed to finish all twenty tasks, we see that there are huge differences between the transfer times of the softwares. ForkLift is the clear winner of the test, finishing all twenty tasks within 21 minutes and 12 seconds. Transmit, the second fastest, finished the same tasks within 41 minutes and 21 seconds.
That means that even the second fastest tool needed almost twice as much time as ForkLift. Cyberduck, which came in third, needed 3.57 times as much as Forklift and FileZilla, the slowest client, needed 4.33 times as much.
If you want to choose the best file transfer client, you should take into consideration how reliable the tool is and how fast it transfers files. It is clear from our test, that even the smallest differences in the execution times can add up easily and quickly. After performing only the twenty tasks in our test, there was a 20 minutes difference between ForkLift, the fastest and Transmit, the second fastest file transfer tool and a 70 minutes difference between ForkLift, the fastest and FileZilla, the slowest tool.
ForkLift is the clear winner of our test because it not only finished on top in 80% of all the tested scenarios but it also had the best combined execution time of all the tested tools.
TL;DR
In our test, we compared the file transfer speed of five advanced file transfer clients: Cyberduck, FileZilla Pro, ForkLift, Transmit and Yummy FTP Pro. We tested the tools using four protocols: FTP, SFTP, WebDAV HTTPS and Amazon S3.
We wanted to find out how fast the tools were uploading, downloading and deleting a single large file (1 or 5 GB) and multiple small files (16471 files with a combined size of 264.8 MB) over the tested protocols.
During our test, we saw bigger differences between the file transfer tools when we were working with a lot of small files. In these cases, ForkLift proved to be especially fast. In some of these scenarios, ForkLift was up to 16 times as fast as the slowest tools. For example, downloading the multiple small files via SFTP took ForkLift only 14 seconds, whereas doing the same took FileZilla 3 minutes and 48 seconds.
The only time when a tool other than ForkLift was in the lead by a large margin was in the case of the deletion of the small files via WebDAV HTTPS. In that scenario, Cyberduck outperformed all the other tested clients because it supports server-side recursive deletion which the other tools don’t.
ForkLift was the clear winner of the entire speed test. ForkLift reached the first place in 80% of the tested scenarios. It also had the best combined execution times using each and every tested protocol. ForkLift completed all 20 tasks together almost twice as fast as the second fastest tool and more than four times as fast as the slowest tool.