Open
Conversation
Advertises a larger HTTP/2 receive window (connection-level or
per-stream) by sending a WINDOW_UPDATE frame. Needed because RFC 7540
makes the connection-level initial window tunable only via
WINDOW_UPDATE — not SETTINGS — leaving the spec default of 64 KB as
the only reachable value without an API like this.
In hex's `mix deps.get` — many parallel multi-MB tarball downloads
sharing one HTTP/2 connection — raising the connection window from
64 KB to 8 MB via this function drops 10 runs from 32.7s to 29.2s
(10.8%), matching their HTTP/1 pool.
Deliberately asymmetric with get_window_size/2 (which returns the
client *send* window). Docstrings on both carry warning callouts
spelling out send-vs-receive so callers don't assume they round-trip.
Target is :connection or {:request, ref}; grow-only (shrink attempts
return {:error, conn, %HTTPError{reason: :window_size_too_small}});
new_size validated against 1..2^31-1. Tracks the advertised peak on
new receive_window_size fields on the connection and stream.
ericmj
force-pushed
the
ericmj/http2-connection-window-size
branch
from
8eb787d to
530f3ec
Compare
Coverage Report for CI Build 0Coverage increased (+0.05%) to 87.684%Details
Uncovered Changes
Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Advertises a larger HTTP/2 receive window (connection-level or per-stream) by sending a WINDOW_UPDATE frame. Needed because RFC 7540 makes the connection-level initial window tunable only via WINDOW_UPDATE — not SETTINGS — leaving the spec default of 64 KB as the only reachable value without an API like this.
In hex's
mix deps.get— many parallel multi-MB tarball downloads sharing one HTTP/2 connection — raising the connection window from 64 KB to 8 MB via this function drops 10 runs from 32.7s to 29.2s (10.8%). The time is for the wholemix deps.getcommand so the actual speed up for the HTTP requests is actually a higher percentage.Deliberately asymmetric with get_window_size/2 (which returns the client send window). Docstrings on both carry warning callouts spelling out send-vs-receive so callers don't assume they round-trip.
Target is :connection or {:request, ref}; grow-only (shrink attempts return {:error, conn, %HTTPError{reason: :window_size_too_small}}); new_size validated against 1..2^31-1. Tracks the advertised peak on new receive_window_size fields on the connection and stream.