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. 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.

Mac Os Ftp Client

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, 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.

Free Ftp Mac

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. Hi Naj, thank you for your comment. You are right, not everything is about speed, but as the title of the blog post says, this post is about a speed test.

We wanted to compare the tools based on their transfer speed because we worked hard to improve the transfer speed of ForkLift. We believe that we’ve designed ForkLift the way it makes managing and working with files smooth, but it’s not so easy to objectively compare the smoothness of different tools. We offer a free trial version of ForkLift so that everybody can decide based on their subjective criteria how they like working with it before buying it. In the future we will try to write more about other factors which should be considered before choosing the right FTP tool.

There’s a growing trend among utility applications for Mac users. Instead of a simple try-before-you-buy trial app, many Mac developers are going with a free version of an app with useful functionality, but with an upgrade to a paid version that has more features or unlocks features you really want. Here’s a good example of a Mac utility which could be used to replace the Finder with a laundry list of more useful, albeit somewhat geeky, features– maybe not for the average Mac user– but certainly beneficial for many of us. Three words: F.T.P.

File transfer protocol. Panes, Not Pains The Mac’s Finder basically is a built-in file management utility; an app which makes it easier to find files, perform certain functions, even act as a launcher and viewer. It took Apple a long time to fix the Finder’s many idiosyncrasies and add 21st century features. Today’s Finder has multiple tabs, a useful (but colorless) sidebar, and a modestly customizable toolbar. What’s missing in Finder often shows up in, a free Finder replacement-like utility for the Mac, an app that is both familiar and instantly usable, but also contains a long list of options more suitable for experienced Mac users; features you won’t find in the Finder.

Commander One has options for different viewing modes, a button to view hidden files, and tabs for multiple Finder-like windows. In addition to the basic Finder functions, Commander One has a number of tools which improve your workflow. For example, move a file to a folder and change the name along the way.

Spotlight search is built-in, of course, but so is the file viewer which handles both hex and binary files as well as standard text, media files, image files, and HTML. Need root access? Commander One gives it to you, but also includes a history of recently opened folders and files. Yet, the user interface has options for customizing fonts and colors, and you can setup customizable hotkeys. All that is free.

The not-so-free version is called the Commander One Pro and it goes well beyond typical Finder functionality with built-in sFTP/FTP for file transfers to remote computer, options to compress and extract RAR, TBZ, TGZ, even 7z, as well as.zip. The PRO version also lets you mount iOS devices– iPad and iPhone– directly to the desktop. Experienced Mac users will appreciate quick access to Terminal, a list of running processes in the process manager (adding functionality from Activity Monitor), and a few themes so you can bring back some of the color Apple took away from the Finder.

Commander One is not as robust as the popular, but the PRO version adds enough features to make the lower price tag a worthy consideration.