chore: Broadcast to concurrent Sinks in Fanout #11197
Closed
Conversation
This file contains 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
|
✔️ Deploy Preview for vector-project ready! 🔨 Explore the source changes: 68fe2b5 🔍 Inspect the deploy log: https://app.netlify.com/sites/vector-project/deploys/61fd9cb5b8bf3900083e6860 😎 Browse the preview: https://deploy-preview-11197--vector-project.netlify.app |
github-actions
bot
added
domain: core
This commit tries to avoid the slow receiver problem in our Fanout implementation by running downstream Sinks in their own spawned tasks, feeding incoming Events into a broadcast channel. This commit is VERY ROUGH. The hope is to get a sense of whether this approach works in practice, what it's limits are. Success is lighting up the CPUs vector runs on as that will get us back into a more familiar optimization loop. Signed-off-by: Brian L. Troutwine <brian@troutwine.us>
blt
force-pushed
the
fanout_with_tasks
branch
from
d98222b
to
68fe2b5
Compare
blt
changed the title
blt
added a commit
that referenced
this pull request
Feb 5, 2022
This commit is kind of a peer to #11197, in pursuit of #10144. The basic idea here is we want to get rid of the lock-step behavior that a strict Sink requires for fanning out, because we know that we have issues with slow receivers. This commit is not nearly so intrusive as #11197 but does allow for incremental progress among the cohort of downstream sinks. I still have some tests commented out. The error propagation story here is yet to be worked on. Signed-off-by: Brian L. Troutwine <brian@troutwine.us>
blt
added a commit
that referenced
this pull request
Feb 7, 2022
This commit is kind of a peer to #11197, in pursuit of #10144. The basic idea here is we want to get rid of the lock-step behavior that a strict Sink requires for fanning out, because we know that we have issues with slow receivers. This commit is not nearly so intrusive as #11197 but does allow for incremental progress among the cohort of downstream sinks. I still have some tests commented out. The error propagation story here is yet to be worked on. Signed-off-by: Brian L. Troutwine <brian@troutwine.us>
|
Closing in favor of #11206 |
blt
added a commit
that referenced
this pull request
Feb 8, 2022
This commit is kind of a peer to #11197, in pursuit of #10144. The basic idea here is we want to get rid of the lock-step behavior that a strict Sink requires for fanning out, because we know that we have issues with slow receivers. This commit is not nearly so intrusive as #11197 but does allow for incremental progress among the cohort of downstream sinks. I still have some tests commented out. The error propagation story here is yet to be worked on. Signed-off-by: Brian L. Troutwine <brian@troutwine.us>
blt
added a commit
that referenced
this pull request
Feb 8, 2022
This commit is kind of a peer to #11197, in pursuit of #10144. The basic idea here is we want to get rid of the lock-step behavior that a strict Sink requires for fanning out, because we know that we have issues with slow receivers. This commit is not nearly so intrusive as #11197 but does allow for incremental progress among the cohort of downstream sinks. I still have some tests commented out. The error propagation story here is yet to be worked on. Signed-off-by: Brian L. Troutwine <brian@troutwine.us> Co-authored-by: Luke Steensen <luke.steensen@gmail.com>
blt
added a commit
that referenced
this pull request
Feb 8, 2022
This commit is kind of a peer to #11197, in pursuit of #10144. The basic idea here is we want to get rid of the lock-step behavior that a strict Sink requires for fanning out, because we know that we have issues with slow receivers. This commit is not nearly so intrusive as #11197 but does allow for incremental progress among the cohort of downstream sinks. I still have some tests commented out. The error propagation story here is yet to be worked on. Signed-off-by: Brian L. Troutwine <brian@troutwine.us> Co-authored-by: Luke Steensen <luke.steensen@gmail.com>
blt
added a commit
that referenced
this pull request
Feb 9, 2022
This commit is kind of a peer to #11197, in pursuit of #10144. The basic idea here is we want to get rid of the lock-step behavior that a strict Sink requires for fanning out, because we know that we have issues with slow receivers. This commit is not nearly so intrusive as #11197 but does allow for incremental progress among the cohort of downstream sinks. I still have some tests commented out. The error propagation story here is yet to be worked on. Signed-off-by: Brian L. Troutwine <brian@troutwine.us> Co-authored-by: Luke Steensen <luke.steensen@gmail.com>
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.
This commit tries to avoid the slow receiver problem in our Fanout
implementation by running downstream Sinks in their own spawned tasks,
feeding incoming Events into a broadcast channel. This commit is VERY
ROUGH. The hope is to get a sense of whether this approach works in
practice, what it's limits are. Success is lighting up the CPUs vector
runs on as that will get us back into a more familiar optimization loop.