You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is now possible to set the window size on the session & its streams. By default, it's 64KB which is too small. When connecting to really remote servers, there can be even 250ms latency. That is 4 packets per second! What a fantastic speed of 256KB/s.
Okay, you might want to connect to a close server, assume 20ms ping. That's just 50 packets per second.
Meaning: 50 * 16 = 3200KB/s.
Describe the solution you'd like
There are many 1Gbps connections out there. Let's make the session window size 128MB and the stream window size at least 16MB. Okay, that's overkill, see my comment above below.
This way, with 250ms latency the speed will be 64MB/s (512Mbps).
This should be left to the OS. You may have 11 terabit cybernetic spinal tap, won't mean much if the latency is through the roof too.
It probably should, but the HTTP2 spec did not think so, so that is not really an option. Unless you think that the implementation should be rewritten to use OS-supported HTTP/2 connections? I believe only Windows 10 and macOS provide any such APIs.
Besides, the OS will also provide its own connection window at the TCP level.
I think it's clear that the window size is a fundamental to achieve good performance. As far as I understand, we are talking about the default value, or am I missing something? I do not think we are providing enough documentation on this topic - so maybe the best step is to document how to tune this parameter?
As far as I understand, we are talking about the default value, or am I missing something?
Correct. I don't think leaving the window unlimited is a good option since it might disable parallelism. We don't want one session to consume all the bandwith - there should be space left for others as well.
so maybe the best step is to document how to tune this parameter?
Sure. I think it's crucial to change the default value to something higher anyway.
FWIW the higher window size become problematic in lossy networks.
Wdyt @jasnell? What should be a good default value?
My approach to determine the best value would be to run tests and simulations across all conditions. This is probably a significant chunk of work.
(I did similar research during my Ph.D.).
I hope this research to be available online, maybe we can see what values nginx or cloudflare use for example.
Activity
szmarczak commentedon Apr 27, 2021
If 128MB seems too much, I'd prefer if we didn't go lower than 32MB for the session window size and 4MB for the stream window size.
That way, with 250ms latency the speed would be 16MB/s (128Mbps).
h1z1 commentedon Apr 27, 2021
This should be left to the OS. You may have 11 terabit cybernetic spinal tap, won't mean much if the latency is through the roof too.
kanongil commentedon Apr 27, 2021
It probably should, but the HTTP2 spec did not think so, so that is not really an option. Unless you think that the implementation should be rewritten to use OS-supported HTTP/2 connections? I believe only Windows 10 and macOS provide any such APIs.
Besides, the OS will also provide its own connection window at the TCP level.
mcollina commentedon May 16, 2021
I think it's clear that the window size is a fundamental to achieve good performance. As far as I understand, we are talking about the default value, or am I missing something? I do not think we are providing enough documentation on this topic - so maybe the best step is to document how to tune this parameter?
szmarczak commentedon May 16, 2021
Correct. I don't think leaving the window unlimited is a good option since it might disable parallelism. We don't want one session to consume all the bandwith - there should be space left for others as well.
Sure. I think it's crucial to change the default value to something higher anyway.
[-]Increase HTTP/2 window size[/-][+]Increase HTTP/2 window size by default[/+]mcollina commentedon May 16, 2021
FWIW the higher window size become problematic in lossy networks.
Wdyt @jasnell? What should be a good default value?
My approach to determine the best value would be to run tests and simulations across all conditions. This is probably a significant chunk of work.
(I did similar research during my Ph.D.).
I hope this research to be available online, maybe we can see what values nginx or cloudflare use for example.
tch1121 commentedon Nov 19, 2021
v17.1.0
no speed increase
deno fetch can be very fast
szmarczak commentedon Nov 19, 2021
@tch1121 you've missed
initialWindowSizetch1121 commentedon Nov 19, 2021
@szmarczak succeed, thank
mcollina commentedon Nov 19, 2021
@szmarczak I'm
happy to increase this quite significantly, would you send a PR?
doc: improve localWindowSize event descriptions
doc: improve localWindowSize event descriptions
doc: improve localWindowSize event descriptions
8 remaining items
http2: increase default window sizes
http2: increase default window sizes