cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Slow Upload Performance on High-Bandwidth connections on windows

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Mon, 4 Feb 2013 22:31:03 +0100 (CET)

On Mon, 4 Feb 2013, Christian Hägele wrote:

> You are right that this is ugly if you were dependent on that workaround.
> However, I believe that not many people are experience these problems. I
> don't know when the CURL_MAX_WRITE_SIZE was lowered from 20Kib to 16KiB, but
> there is a chance that the problem only occurred with a send size of 20KiB.

No. We decided to set the size to 16K way back in the age of dawn, long before
we had any SNDBUF work-arounds introduced. Alas, we didn't get the SNDBUF
problems with 20K, we got (and worked around) them with 16K buffers.

> 1. Get rid of setting the SO_SNDBUF-option to 16416 via
> Curl_sndbufset-function unless you are running Windows older than Vista.
> Personally I would like to get rid of this completely, but I understand you
> don't want to break anything for existing users.

Ack. I would like to see this done.

> 2. Add command-line options for the curl-command-line-tool for setting
> SO_SNDBUF and SO_RCVBUF. That would be good because if you are running a OS
> that doesn't do a good job of determine the right buffer-size that options
> could improve transfer- speed a lot. (e.g. Linux pre 2.6.16)

I don't think this is strictly needed. We never had any reports of problems on
these and we did uploads long before 2.6.16 was born and we've had many users
use that or older linux kernels as well. I think we can leave that until
someone actually wants or needs it.

> I already started to write the changes for no 2). I have a question for
> that: Right now I implemented this via the CURLOPT_SOCKOPTFUNCTION function.
> However, some other options (e.g. TCP_NODELAY) have their own option in
> libCurl. Has this any special reason?

A simple reason: stuff that we can assume to be commonly requested or used by
applications get to have their own option so that not every single user of
libcurl would have to implement the same thing.

-- 
  / daniel.haxx.se

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-02-04