add worker_limit
option for server code generation
#3376
Merged
+132
−2
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.
Overview
When executing a child resolver, a goroutine is created each time if there are multiple fields.
For example, if two fields are in 10,000 objects, and they are required to execute a child resolver, 20,000 goroutines will be created at once with a single request. Since each goroutine requires at least 2 KiB, each request requires approximately 41 MiB for ONLY goroutines.
In this PR, as discussed in #3371, I introduced an option to prevent unintended big memory pressure by restricting goroutines generated at once using a semaphore. To minimize the difference in automatically generated code between before and after this patch is merged, if
worker_limit
is not set, there is no diff from the previously generated code.If you set it as above, the following code will be generated.
Note that
worker_limit
is an option that reduces memory consumption at the expense of concurrency, so excessive restrictions will unnecessarily prolong execution times and degrade application performance.I appreciate @StevenACoffman for sharing this idea with me.
I have: