Cyberduck feels sluggish: what to measure first

Slow is not a measurement, and that is the whole problem. Four unrelated things get described the same way. The directory listing takes seconds to appear. The transfer rate sits far below the line speed. The transfer finishes and then the application appears to hang. Or many small files crawl while one large file is fine. Each has a different cause and a different setting, and changing settings before knowing which one is in play tends to make two of the four worse.

The good news is that separating them takes about five minutes and needs nothing that is not already installed.

Tell the four apart before changing a setting

What you observe	What is actually slow	Where the fix lives
Folders take seconds to list	Round trip latency and listing cost	Browser settings, hidden files
Throughput far below line speed	Connection count or bandwidth limit	Transfers, bandwidth toolbar
Finishes, then hangs at the end	Segment merge	Segmented download setting
Many small files crawl, big ones fine	Per file overhead	Permissions and timestamp settings

The fourth row is the one that misleads most often, because it feels like a network problem and is not. Per file overhead means that a transfer of ten thousand files spends most of its time on operations that have nothing to do with the bytes, and no amount of extra bandwidth improves it.

Before touching anything, establish a baseline. Move one large file, note the rate, then move the same file with a different tool against the same server. If both are equally slow the client is not the variable and the rest of this is wasted effort. That check takes two minutes and saves an afternoon more often than it should.

Measure with the transcript, not with a stopwatch

The protocol transcript shows requests and responses as they happen, which turns a vague impression into a timeline. It is not in the interface. Open a terminal and run:

log stream --predicate '(process == "Cyberduck") && (category == "transcript")' --level info

Leave that running and reproduce the slow operation. What matters is the gap between lines. A long pause before the first response is latency or a server under load. A rapid burst of requests with a small pause after each is per file overhead. A steady stream with no obvious gaps means the bytes are simply moving at the rate the link allows, and the answer is that nothing is wrong.

For anything less protocol specific, the debug log carries the detail. Turn on Enable debug log in the preferences under Connection, reproduce once, then read ~/Library/Logs/Cyberduck/cyberduck.log. The same section of the preferences has a button that reveals the file.

Running these before changing settings matters more than it sounds. Several of the settings below trade one kind of speed for another, and without a measurement there is no way to tell whether a change helped or moved the cost somewhere less visible.

Throughput: the connection mode is the main lever

Cyberduck offers three transfer connection modes, set under Preferences and then Transfers and then Transfer Files, or per bookmark under Edit Bookmark and then Transfer Files.

Use browser connection reuses the connection the browser window already has. Nothing else opens. This is the correct choice when a server permits only one connection per user, and it is the slowest by design, because browsing stops while the transfer runs and the file transfer is reported only at the bottom of the browser window with no detailed progress.

Open single connection adds one dedicated connection alongside the browser and transfers sequentially. Predictable, gentle on the server, and the sensible default for a shared host.

Open multiple connections transfers files concurrently. This is the setting that produces a large improvement on many small files, and it is the one most often left unchanged because the default was never revisited.

Above that sits a limit on how many connections are actually used, set from the toolbar dropdown in the transfer window on macOS. It governs three things at once: how many transfers run in parallel in the Transfers window, how many connections a segmented download uses, and how many connections a multiple file transfer opens. When a queued transfer shows the message about maximum allowed connections being exceeded and waiting, that limit is what it is waiting on.

Raising it is not automatically better. Many servers throttle or refuse beyond a handful of concurrent connections, and a limit set too high produces refused connections that get retried, which is slower than a lower number that succeeds cleanly.

The bandwidth limit that nobody remembers setting

A transfer capped at an oddly round number is almost always a throttle rather than a network condition. Cyberduck can limit the maximum bandwidth a transfer is allowed to use, set from the Bandwidth control in the transfer window's toolbar with the default configurable in the preferences.

The feature exists for a good reason, which is keeping an upload from consuming the whole connection and making everything else on the machine unusable. The problem is that the setting persists. A limit applied during a call six months ago is still applied today, and the symptom is a transfer that sits at exactly the same rate regardless of file, server or time of day.

That constancy is the giveaway. Real network limits fluctuate. A throttle does not. If the rate is suspiciously stable, check the Bandwidth control before investigating anything else.

Many small files: the two documented penalties

This is the case with the clearest official answer, and it is worth quoting the shape of it because it is easy to disbelieve.

The project documents that enabling the change of permissions slows down the transfer rate when uploading many files with FTP. It documents the same penalty separately for modification dates: enabling the change of modification date slows down the transfer rate when uploading many files with FTP.

Both are under Preferences and then Transfers, in the Permissions and Timestamps sections. Both send an extra command per file, which is invisible on ten files and dominant on ten thousand.

The catch is that turning both off is not free. The documentation is explicit that synchronisation requires the timestamp options to be enabled in order to work at all. Modification dates are how a sync decides what has changed, so disabling preservation to speed up an upload silently breaks the next sync.

The workable arrangement is to treat them as different jobs. A bulk one way upload does not need timestamps preserved and runs faster without them. A directory being kept in sync does, and pays the cost. Trying to have one configuration serve both is where people end up with a sync that quietly stops detecting changes.

The transfer filter helps here too. A regular expression under the preferences excludes matching files before they are queued, and the default pattern already removes .DS_Store, .svn and CVS entries along with backup files. On a directory tree carrying a lot of metadata, extending that pattern removes more work than any connection setting will.

One further setting decides how much work a repeated transfer does at all. When files already exist at the destination, the action chosen under the Downloads and Uploads sections governs the cost. Overwrite restarts every file from scratch and moves the existing copies to the trash, which is the most expensive option available and is frequently left selected. Compare skips files whose checksum matches, falling back to modification dates when the server offers no checksum. Resume appends to existing files and skips those already matching in size and checksum. Skip transfers nothing that is already there. On a directory pushed repeatedly with only a handful of changes, moving from Overwrite to Compare is usually the single largest improvement available, and it costs nothing.

Leaving the setting on Prompt has its own cost, which is a person. A transfer that stops to ask about each conflicting file is not slow in any technical sense, but it finishes when someone comes back to the machine, which is generally the metric that matters.

The hang at the end is the merge

A download that reaches 100 percent and then appears frozen is usually segmented downloading doing its final step.

The feature is enabled under Preferences, Transfers, General, Downloads, as the option to download a file with multiple connections in segments. Files larger than 100MB are split into segments and fetched over several connections at once, then reassembled into the actual file. The documentation states plainly that merging the segments may take a considerable amount of time. On a very large file this can be minutes of apparent inactivity after the network work is done.

Two conditions are worth knowing. The server has to support concurrent connections for the feature to help at all, so on a host that permits one connection per user it adds nothing. And if any segment fails to arrive, the downloaded parts are saved into a folder and the file cannot be reconstructed without downloading it again or resuming the transfer. That failure mode is the reason some people turn the feature off entirely on unreliable links, accepting a slower download in exchange for one that does not need repeating.

If the wait is at the end and the machine's disk is busy rather than its network, the merge is the answer, and the only real remedy is to decide whether the throughput gain is worth it for the files in question.

Browsing latency is a different problem

Listing delay is not transfer speed and none of the settings above touch it. A remote listing costs a round trip plus whatever the server takes to enumerate the directory, and on a folder with tens of thousands of entries the server is the constraint.

Two things help. Showing hidden files makes every listing larger, and on S3 it also brings in previous revisions of objects, so leaving that off when it is not needed is a real saving. And the outline view expands folders in place rather than reloading a new listing for each navigation step, which cuts the number of round trips when working up and down a deep tree.

Beyond that the honest answer is that the latency belongs to the server and the link. Comparing the same listing through another client confirms this quickly, and when both are slow the tuning to do is on the server side.

What to change first

Run the transcript command, reproduce the slow operation once, and look at where the gaps are. Then change exactly one thing: the transfer connection mode if throughput is low, the timestamp and permission settings if small files are the problem, and nothing at all if the gaps show the server thinking.

If the measurement shows the tool is fine and the real cost is switching between a transfer window, a terminal and a Finder window all session long, that is not a speed problem with this client. It is an argument for a file manager that keeps those in one window, and Atriens is one place to start.