How FTP by Zaweba moves several files at once
FTP by Zaweba runs uploads and downloads side by side on their own connections. Here is how to set the number, and what happens when a host says no.
Uploading a site one file at a time is slow, and not because the files are large. Most of the waiting is the back and forth between your PC and the server for every single file. Running several transfers side by side hides much of that waiting, which is why FTP by Zaweba does it by default.
Each upload or download in a batch can run on its own connection to the server. While one file is waiting for the server to answer, another is already sending data, and a folder of a few hundred small files finishes far sooner than it would in single file.
Choosing how many
The setting lives in File, Options, on the Transfers part, and it takes a number from 1 to 10. The default is 3. That is a sensible middle ground: noticeably faster than one, and low enough that ordinary shared hosting tends to accept it.
Raising it helps most when you are moving many small files, such as a theme folder or a set of thumbnails. It helps less with a handful of large files, where your upload speed is the real limit. Lowering it to 1 makes sense when a host is strict, or when you want transfers to happen one after another while you are learning how a site is laid out.
When the server says no
Many hosts limit how many connections one account can have open at once. When the limit is reached the server refuses the next connection with a 421 reply. FTP by Zaweba does not stop or throw the batch away when that happens. It carries on with the connections it already has, says so in the log, and uses that number from then on. You do not have to guess the host's limit; the app finds it for you, and you can bring the setting down to match if you would rather it never tried for more.
The Disk view scans in the same spirit. It runs over a few connections, backs off on 421 errors and carries on with fewer, and its own count is a per-site setting called scan connections, with 3 described as safe on shared hosts.
Order still matters for deletes and renames
Running things side by side raises an obvious worry. If you queue some uploads into a folder and then delete that folder, could the delete happen first? It cannot. Deletes and renames wait for the transfers queued before them, so a folder is deleted only after its contents. You can queue a mix of jobs and trust the result to match the order you asked for.
Watching it work
The bottom panel shows the transfer queue while all this is going on. You can cancel queued and running transfers, retry ones that failed or were cancelled, and clear finished rows. When a host trims your connections, the log is where you will see the note about it, and you can copy the log to the clipboard if you need to send it to the hosting company.
Sensible habits
Leave the setting at 3 until you have a reason to change it. If big batches seem slow and the log shows no refusals, try a higher number and see if it helps. If you see 421 notes regularly, lower the setting so the app is not knocking on a closed door at the start of each batch. On a site shared with other people, remember they may be connected too, and their connections may count against the same limit.
Large jobs such as Put All, Get Entire Site, Put Newer and Sync all move their files as uploads and downloads, so the one setting speeds up all of them. Each of those still shows you the list of files first, so moving faster never means moving blind.
It is not a feature you think about much once it is set. That is rather the point: transfers simply finish sooner, and a fussy host is handled without fuss.
