Speeding Up Bulk FTP with FileZilla’s Concurrent Transfer Queue

Why the Queue Matters When Moving Lots of Files

When you drag a folder of dozens or hundreds of files into FileZilla, you’re not just opening a single connection. The client builds a transfer queue that lists every file to be sent. By default, FileZilla processes that list one file after another, using the same FTP/FTPS/SFTP session for every file. On high‑latency links this serial behavior can make a routine upload feel sluggish.

Enabling Parallel Transfers: The Core Feature

FileZilla’s Limit number of simultaneous transfers setting (Edit ► Settings ► Transfers) controls how many files the queue will pull at once. Setting it to 1 keeps the default serial mode. Raising it to 4, 8 or more spawns that many worker threads. Each thread opens its own data channel (PORT/PASV or EPSV/EPRT) while the control connection stays shared. The result is a dramatic cut in total transfer time for homogeneous small files.

How the Client Reuses the Control Connection

When a thread starts, FileZilla issues a PORT or PASV command on the existing control channel. The server replies with the address and port for the new data connection, and the thread opens it. Because the control session is reused, the client avoids the overhead of re‑authenticating or re‑establishing a session for each file.

Concrete Example: Moving 50 2‑MB Images Over FTPS

1. Launch FileZilla 3.66.0 or newer.
   • Navigate to Edit ► Settings ► Transfers.
   • Set Limit number of simultaneous transfers to 4.
   • Click OK.
2. Connect to your FTPS server (explicit FTPS, 21/990). Verify that the site profile has a Maximum simultaneous transfers of 2 or less; FileZilla will respect that cap even if the global setting is higher.
3. Drag 50 image files (~2 MB each) from the local folder into the remote pane.
   • The Transfer tab shows 50 queued entries.
   • With the limit set to 4, you’ll see up to four rows in the Active section, each representing a separate data channel.
4. Start the transfer. On a 100 Mbps link with 80 ms RTT, the total time measured (via the Transfer log or a stopwatch) drops from roughly 45 seconds (serial) to about 12 seconds (parallel).

Below is a simple table summarizing the observed times. The numbers are illustrative; your environment may vary.

Simultaneous Transfers	Estimated Time
1 (serial)	≈45 s
4 (default‑like)	≈12 s
8 (high concurrency)	≈9 s (diminishing returns)

Trade‑offs and Limitations

• CPU & Memory: Each thread consumes resources. On low‑end machines, setting the limit too high can cause sluggishness or crashes.
• Server Throttling: Some FTP servers limit connections per IP. Exceeding that can trigger temporary bans or throttling.
• Firewall Constraints: Passive mode opens a new port for each data channel. If the firewall only allows a single passive port range per connection, additional transfers may fail unless the server’s passive port range is wide enough or active mode is used.
• Site Profile Limits: FileZilla honors the Maximum simultaneous transfers value defined in a site profile. Even if the global setting is higher, the local cap wins.

How to Verify the Effect

1. Open the Message Log (View ► Message Log). Look for lines like 229 Entering Extended Passive Mode (|||50000|) – each indicates a new data channel.
2. Use a network sniffer (e.g., Wireshark) to confirm that the control connection remains single while multiple data connections appear.
3. Run a comparison test on a controlled LAN or VPN: upload the same file set with the limit set to 1, then to 4 or 8, and record the total time.

Practical Takeaway

If you routinely move bulk files over FTP/FTPS/SFTP, enable concurrent transfers in FileZilla. Start with a modest value (4 or 8) and watch the transfer log. Adjust upward only if you’re sure the server can handle the load and your firewall permits multiple passive ports. This simple tweak can cut transfer times by a factor of three or more on high‑latency links, saving time and bandwidth without changing your server configuration.