From time to time we hear from users that Transmit is using a lot of CPU and they wonder what is going on. In this write-up we’ll explain how Transmit uses your CPU and just how fast it is. We take pride in the performance of all our software and Transmit is no exception. In Transmit 5 we set out to push modern CPUs to their limit and by default we transfer 5 files at once. Typically what this means is the OS puts one file transfer onto one of the CPU cores. Modern Macs ship with powerful multi-core CPUs designed to handle big work loads and Transmit utilizes that power.
We realize that transferring 5 files at once may simply use too much CPU time for some users. The quick way to reduce CPU usage is to change the
Transfer up to X files simultaneously located in
Preferences > Transfers to a lower number to suit your desired CPU load. You can also limit connections by server in Advanced Server Settings, located in
Preferences > Advanced.
The Technical Details
Our goal with Transmit has always been to be the fastest and most user-friendly file transfer client on the market. When tuning Transmit we ask ourselves, “how fast can we make this transfer a file?”. In simple terms, that means we aren’t going to artificially limit the file transfer speed, we feel most users want their files transferred as quickly as possible. That’s all well and good you might say, but why does Transmit max out a CPU core at 100% when transferring a file? In this article, we’ll be focusing on SFTP performance since it is the most popular and most processor intensive protocol Transmit supports.
There are three main factors that can influence SFTP performance of Transmit: CPU, hard drive and network speed. With PCIe SSD hard drives, modern networking speeds and multiple core CPUs, we have a lot of potential power at our disposal. Modern hard drives and networks are very fast, so that leaves the CPU as the bottleneck. In SFTP there is a lot going on to keep your data secure and files transferring quickly. Let’s start from the bottom up.
The SSH protocol, what SFTP is built upon, uses relatively small blocks of data when requesting files from a server. For each file chunk we read, we must first send a request for it, then the server sends a reply with the data. Since these blocks are small, we must send and receive a lot of requests. Transmit uses a concept called pipelining to speed up network activity so it’s not waiting for the server to reply to a request before sending the next request. This adds considerable networking overhead, but also speeds up transfers by orders of magnitude. Second, each block of data sent and received is encrypted using the latest encryption techniques. Lastly, reading and writing data on a fast network simply takes CPU time; the data is coming and going quickly.
Here is the breakdown of what Transmit is doing with a single CPU core when downloading a large file:
- 70.5% - Reading data off the network at the lowest OS level
- 9.2% - Decrypting read data off the network
- 4% - Building/handling data request timeouts
- 2% - Building a request for the next block of data
- 5% - Encrypting the request for the next block of data
- 8.1% - Miscellaneous overhead servicing the above tasks
Out of 100% single CPU core utilization for a file transfer, we spend 98.8% of the CPU time directly dealing with transferring the file. The remaining 1.2% is used for updating progress, dispatching messages across the application and OS level runtime tasks. The main thread, or the thread that deals with interacting with the user interface, sits at nearly 0% CPU core usage.
Wrapping it Up
We hope this helps clear things up. While it may be a bit alarming to see your CPU being pushed to its limits, the OS is extremely good at scheduling tasks and scaling back CPU speeds if it is being taxed. In the vast majority of cases, you won’t even notice Transmit humming along in the background, just the way we want it.