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

x/net/http2: Ability to set initial flow control in transport. #27931

Open
gaillard opened this Issue Sep 29, 2018 · 5 comments

Comments

Projects
None yet
3 participants
@gaillard

gaillard commented Sep 29, 2018

What version of Go are you using (go version)?

Go 1.11

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

linux + darwin on amd64 and android on arm.

What did you do?

Made an http2 request.

What did you expect to see?

This is a feature request.

What did you see instead?

Configurable values such as in the Server but for thetransport would be great :D
As the latency gets higher this has a sizable effect.
Currently it is at some huge value for connection and 4MB for stream. In a server that does lots of calls out that might want to be reduced, and in known high latency cases it may go up.

@dmitshur

This comment has been minimized.

Show comment
Hide comment
@dmitshur
Member

dmitshur commented Oct 3, 2018

@bradfitz

This comment has been minimized.

Show comment
Hide comment
@bradfitz

bradfitz Oct 3, 2018

Member

How does increasing latency affect this?

If anything I'd expect this to increase latency (while reducing CPU / increasing throughput).

Have you run any numbers?

Member

bradfitz commented Oct 3, 2018

How does increasing latency affect this?

If anything I'd expect this to increase latency (while reducing CPU / increasing throughput).

Have you run any numbers?

@gaillard gaillard changed the title from x/net/http2: Ability to set max frame size in transport. to x/net/http2: Ability to set initial flow control in transport. Oct 3, 2018

@gaillard

This comment has been minimized.

Show comment
Hide comment
@gaillard

gaillard Oct 3, 2018

@bradfitz Sorry I meant the flow settings that are on the server.

gaillard commented Oct 3, 2018

@bradfitz Sorry I meant the flow settings that are on the server.

@bradfitz

This comment has been minimized.

Show comment
Hide comment
@bradfitz

bradfitz Oct 3, 2018

Member

I think we have an existing bug open about auto-tuning the various buffers to the calculated bandwidth delay product somewhere. We try to avoid having too many knobs when possible.

Member

bradfitz commented Oct 3, 2018

I think we have an existing bug open about auto-tuning the various buffers to the calculated bandwidth delay product somewhere. We try to avoid having too many knobs when possible.

@bradfitz bradfitz removed the WaitingForInfo label Oct 3, 2018

@gaillard

This comment has been minimized.

Show comment
Hide comment
@gaillard

gaillard Oct 3, 2018

That would certainly be nice :) for both transport and server. However for servers especially (but might as well both), I would imagine many would still want to cap max memory and therefore even if BDP shows higher is better, a knob would be needed.

gaillard commented Oct 3, 2018

That would certainly be nice :) for both transport and server. However for servers especially (but might as well both), I would imagine many would still want to cap max memory and therefore even if BDP shows higher is better, a knob would be needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment