Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make HTTP2 window size configurable #145

Closed
FinleyMcIlwaine opened this issue May 14, 2024 · 6 comments · Fixed by #178
Closed

Make HTTP2 window size configurable #145

FinleyMcIlwaine opened this issue May 14, 2024 · 6 comments · Fixed by #178
Assignees
Labels
enhancement New feature or request performance Performance related issues priority: high Usability of the library severely hindered

Comments

@FinleyMcIlwaine
Copy link
Collaborator

http2 uses a default connection window size of 1MB per connection and 256KB per stream, which can cause data to pile up on a receiver's heap if they can't keep up. We've observed this in the stress tests. The standard fix for this is to reduce the window size. http2 makes this configurable, although a brief test where we tried to reduce the window size on the client led to bus errors in the server. We should make this configurable in grapesy as well, and see if we can avoid/fix the bus errors.

@FinleyMcIlwaine FinleyMcIlwaine added enhancement New feature or request priority: low Minor enhancements performance Performance related issues labels May 14, 2024
@edsko
Copy link
Collaborator

edsko commented May 15, 2024

I just noticed confBufferSize in the settings, maybe we should be using that instead?

@FinleyMcIlwaine
Copy link
Collaborator Author

I have confirmed that the recent patch to http-semantics fixes the bus errors/segfaults we saw here when adjusting the window size. I have also confirmed that lowering the window size does indeed lower heap residency in the receiver for our stress test.

The default connection window size in http2 is relatively large (1048576 bytes), so the stress test was is actually limited by the initial window size in Network.HTTP2.H2.Settings.defaultSettings, which is also a relatively large 262144 bytes. With those default window sizes, in our server streaming RPC stress test, we see this:

Screenshot 2024-06-18 at 5 10 52 PM

Halving that initial window size manually in grapesy with something like this in connectInsecure

...
          , HTTP2.Client.settings =
              (HTTP2.Client.settings HTTP2.Client.defaultClientConfig)
                { HTTP2.Client.initialWindowSize = 262144 `div` 2
                }
...

the residency drops:

Screenshot 2024-06-18 at 5 33 51 PM

Halving it again:

Screenshot 2024-06-18 at 5 37 11 PM

So making the http2 window size configurable does seem like it would be a good improvement.

@edsko
Copy link
Collaborator

edsko commented Jun 19, 2024

Ok, awesome. Good to know that our understanding of the memory behaviour is correct now. Let's add a grapesy flag that allows to set these two parameters, and when we document memory behaviour in the yet-to-be-written manual, we should mention this.

@edsko
Copy link
Collaborator

edsko commented Jun 19, 2024

Relevant: kazu-yamamoto/http2#121 (comment)

@edsko edsko added priority: medium Should be done before the library can be considered complete and removed priority: low Minor enhancements labels Jun 26, 2024
@edsko
Copy link
Collaborator

edsko commented Jul 2, 2024

We need four parameters to be configurable:

  • max concurrent streams
  • stream window size
  • connection size
  • number of workers

and we should also pick our own defaults independent from the defaults from http2 (or network-control).

We need to ensure that we document in the Haddocks the relationship between these three parameters.

@edsko edsko added priority: high Usability of the library severely hindered and removed priority: medium Should be done before the library can be considered complete labels Jul 2, 2024
@edsko
Copy link
Collaborator

edsko commented Jul 2, 2024

Increasing priority to high due to #169 (comment) .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request performance Performance related issues priority: high Usability of the library severely hindered
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants