I am running vsftpd 2.2.1 on an Ubuntu 8.04 machine with a pretty straight-forward configuration and am experiencing a strange issue regarding uploads to the machine via FTP. If I upload text files the transfer speed is about 70 KB/s, if I upload binary data (zip file, etc.) the transfer speed is about 50 times as fast. I have used several different clients on different operating systems, different file sizes, etc. I have tried in both binary and ASCII modes for the text file transfer and nothing seems to make a difference. Has anybody seen this before or have any idea what might be causing this behavior?
Update:
The FTP server is on a different subnet as the client machines that I previously tested with and have a Linux gateway in between, it appears that the issue is only occurring when machines on a different subnet connect through the gateway to the FTP server. When machines on the same subnet as the FTP server upload text files the issues doesn't seem to occur. This still doesn't make much sense but maybe there is an issue with the ip_conntrack_ftp module used on the gateway.
Update:
It turns out that someone had set up Snort IDS on one side of the gateway which was breaking up FTP packets on approximately newline barriers which caused the lag for text files.
Best Answer
Maybe the line-ending conversions in vsftpd were written inefficiently, and since binary mode is most commonly used, no one has bothered to improve the algorithm used in vsftpd.
Or, it could just be that passing data from a tcp socket out to disk really is a lot faster than having to check every character for CR and LF. The check could introduce enough latency in the connection to reduce your transfer speed.
Are you running tests locally on Ethernet (low latency, would be affected greatly by additional latency) or across the Internet?