HTTP.jl currently advertises the HTTP/2 protocol-default flow-control window of 65535 bytes for both the per-stream window (SETTINGS_INITIAL_WINDOW_SIZE) and the connection-level window, and these are hardcoded at connection setup. Because flow control caps the in-flight unacknowledged bytes, single-stream throughput is bounded by roughly window / RTT. This is fine for small requests but throttles any significant upload or download on a link with non-trivial latency.
I hit this building a gRPC server on HTTP.jl 2.0.0, where large protobuf messages are the common case. Raising the advertised window from 64 KiB to 256 KiB nearly doubled client upload throughput in my setup.
It would be useful to configure this when setting up a server or client, since uploads depend on the server's receive window and downloads on the client's. I have an implementation in a fork and am doing more testing and review before opening a PR if this is something the project would be open to.
HTTP.jl currently advertises the HTTP/2 protocol-default flow-control window of 65535 bytes for both the per-stream window (
SETTINGS_INITIAL_WINDOW_SIZE) and the connection-level window, and these are hardcoded at connection setup. Because flow control caps the in-flight unacknowledged bytes, single-stream throughput is bounded by roughlywindow / RTT. This is fine for small requests but throttles any significant upload or download on a link with non-trivial latency.I hit this building a gRPC server on HTTP.jl 2.0.0, where large protobuf messages are the common case. Raising the advertised window from 64 KiB to 256 KiB nearly doubled client upload throughput in my setup.
It would be useful to configure this when setting up a server or client, since uploads depend on the server's receive window and downloads on the client's. I have an implementation in a fork and am doing more testing and review before opening a PR if this is something the project would be open to.