Daniel Stenberg wrote:
> On Wed, 10 Oct 2007, Ivan Makale wrote:
>
>> I tried with various options you mentioned and other, without
>> performance improvement. The problem is not the connection time but
>> the transmission time. Just to give an idea:
>>
>> - with command line FTP about 500 kbytes/sec
>> - with curl about 70 kbytes/sec

I couldn't confirm such a big difference, however curl is apparently
somewhat slower. Measuring time on the server unfortunately is not
very precise, as my xferlog doesn't report fractions of a second. So,
I created a file ~8M (actually 8058822 bytes) and uploaded it several
times through a 10mbit ethernet hub from an XP SP2 host.

The system command line tool as well as filezilla could upload it in 8
secs, sometimes 7, i.e. 983K/s~1124K/s, which is roughly the theoretical
max, given the hub bottleneck. However, command line curl uploaded it in
8 secs, and occasionally in 9, i.e. 874K/s~983K/s. I haven't been able
to get a "7", even using all the options that Dan suggested, including
--limit-rate 2M --tcp-nodelay --disable-epsv --ipv4.

I tested various curl versions, 7.15.4, 7.16.2, and 7.17.0, getting the
same results.

Looking at the single data packets sent, I could see that the system ftp
tool always sent 1460 bytes per TCP packet, except the last that had 1082
(5523 total packets sent, including 3 empty handshake ones.) Whereas curl
sends a packet with 324 bytes after every 11 1460 bytes packets (thus
totaling 5906 packets sent, including 2+2 empty ones --for passive handshake.)

I reckon 1460*11 + 324 = 16384, which is probably the buffer size defined
after CURL_MAX_WRITE_SIZE in curl.h.
Received on 2007-10-11