In this case, because of the round trip times of the connection setup and teardown, you may get higher performance with more threads and the smaller files. One thread could be transferring a file while another is setting up or tearing down a connection. It all depends on what resources are your limiting factor.

Dan J. Bernstein (http://www.qmail.org) used this concept in building qmail. While not everyone agrees on his implementation of SMTP, the ability of that server to fully utilize the bandwidth of a host for small messages is hard to argue with.

Update: I am not saying that you will get better performance with multiple threads. It depends on a lot of different factors, both local and remote.

Using multiple threads to maintain multiple connections isn't necesarily the only solution. Frameworks like IO::EventMux and IO::Lambda does single threaded multi-connection management using non-blocking IO.

Your node got me wondering at what point forking more workers fails to improve performance. This is admittedly very environment-specific, but I found it interesting nonetheless. I put together the following simple script as a test:

Environment:

• Client running on w2k3 and connecting to a HP-UX box
• Directory to be transferred contains 340 .pdf files ranging in size from ~10k to ~250k.

You can see that the initial forks provided quite significant performance boosts. However, the improvement began to drop quickly once I was launching more than 7 children. Eventually there was no improvement whatsoever (though no cost, either).

Things to keep in mind:

• These are win32 forks. A *nix system may have very different results
• This script was written specifically for this testcase -- not meant to be very robust (but I did try to make it very readable)