On Fri, 11 Mar 2016, Molina wrote:

> The problem was in the window sizes and tcp buffers. Concretely I had to
> increase the tcp buffer in the following way (on OS X 10.11.3):

Wow. Thanks a lot for your hard work and research on this. Coincidentally, I'm
also the author of an internet draft called "TCP Tuning for HTTP" for which
this sort of information is very interesting!

   https://tools.ietf.org/html/draft-stenberg-httpbis-tcp-01

I do have a bunch of follow-up questions though!

> sudo sysctl -w net.inet.tcp.recvspace=$(( 1024*1024*2 )) # 2MB

Can these values be set programmatically per socket? Did you do any magic
calculations to end up with this new value? Or did you experiment your way to
the optimal value?

Some sources[1] say this config sets the maximum TCP window it can announce,
which to me sounds a bit small while if it is buffers per socket it sounds
pretty big.

Another place[2] says net.inet.tcp.recvspace is the recive buffer size and
that this value, plus net.inet.tcp.sendspace, must be less than
kern.ipc.maxsockbuf.

> sudo sysctl net.inet.tcp.autorcvbufmax=16777216

So this allows the receive buffer to automatically grow to 16MB. Have you
understood how it correlates with net.inet.tcp.recvspace? And again with the
actual value, how did you end up with this number?

> After this tuning both HTTP/1.1 and HTTP/2.0 increased their corresponding
> download speed. After that I tried with the h2o server two tests using
> HTTP/1.1 and HTTP/2:

But how about other clients? Did Firefox/Chrome also work slowly until this
change or did they work fast already without the parameter tweaks?

> it was necessary to use the nghttp utility to increase the per-connection
> window size to 16MB and the per-stream window size to 1MB, having 16
> parallel streams.
>
> I of course also tried to do the same with libcurl, but I did not find any
> way of doing it with the current API. My questions are:
>
> Perhaps I was missing a parameter to actually increase the window size?

We currently don't have any such API. Ideally we should also try to avoid
having one I think because it only leads to the very hard question: what
should a user set the value to? It would be much better if we figure that out
and set a suitable value ourselves. But maybe that's not possible?

In general though, libcurl doesn't really make much use of the HTTP/2 flow
control features so it would probably make sense to more or less by default
use a pretty large window.

> Would it be possible to manually use libnghttp2 to increase the window size?
> In case it is, would doing so interfere with libcurl?

The window is set per-stream and libcurl sets up the streams (using libnghttp2
of course) so in order to get this feature we need to add the ability to
libcurl.

> In case there is no parameter to increase the window size, is expected to
> add it in future versions?

We make libcurl do what we think it should do. If we think it should be able
to set the HTTP/2 stream window size then we make that possible! Feel free to
dig in and help us write that patch. But perhaps we could start with simply
making the default window larger than what it currently is and maybe we can be
fine with that?

[1] =
https://rolande.wordpress.com/2014/05/17/performance-tuning-the-network-stack-on-mac-os-x-part-2/

[2] = http://fmepnet.org/bwdp_tuning.html

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html