Repository navigation
[Fusion] Build subgraph HTTP requests before streaming their results - #10633
Closed
tobias-tengler wants to merge 1 commit into
Closed
tobias-tengler wants to merge 1 commit into
tobias-tengler wants to merge 1 commit into
Conversation
HttpSourceSchemaClient.ExecuteAsync now creates the HTTP request synchronously and hands it to a single async iterator that sends it and reads the results. This drops the outer iterator that stored the whole client request and its token twice, and the nested read iterator.
Contributor
Patch coverage74.2% of changed lines covered (23/31)
Uncovered changed lines (JSON){
"sha": "d4b5c0ed2dc7143b62f3a42ce78ab9a72732985b",
"files": [
{ "path": "src/HotChocolate/Fusion/src/Fusion.Execution/Execution/Clients/HttpSourceSchemaClient.cs", "ranges": [[127, 130], [283, 286]] }
]
}Project coverage: 59.0% (311549/527844 lines) |
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
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.
Every subgraph request sent by
HttpSourceSchemaClient.ExecuteAsyncallocates two async iterators: an outer one that builds and sends the request and stores the whole client request and its cancellation token in its state, and a nested one that reads the response.This PR builds the
GraphQLHttpRequestsynchronously inExecuteAsync, the pattern the native batching path already uses, and hands it to a single iterator that sends it, tracks the transport and reads the results. A failure while building the request now throws fromExecuteAsyncitself instead of from the firstMoveNextAsync; every execution node already calls it inside itstry, and the request batching fallback now catches it so it is still recorded as a per-request batch error.Measured with a gateway benchmark over real
HttpSourceSchemaClients whoseHttpMessageHandlerreturns canned responses:ListWithLookup({ products { id name price } }, a root fetch plus one batched lookup, 2 sends) andSingleFetch({ products { id name } }, 1 send). BenchmarkDotNet's allocated column was unreliable for this async benchmark (missing cells, about 1 KB between two runs of the same build), so allocations come from a probe that readsGC.GetTotalAllocatedBytes(precise: true)over 20,000 sequential requests per round, 5 rounds per run, two runs per build. Each allocation cell lists the per-round value of the two runs. Both builds include #10632, so the baseline row ismainplus that change.main+ #10632main+ #10632The PR allocates 392 B less per subgraph send (784 B with 2 sends, 392 B with 1). Time is unchanged within noise.