chore: Switch from futures channel to tokio in fanout transform #11009
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: 5a3325e 🔍 Inspect the deploy log: https://app.netlify.com/sites/vector-project/deploys/61f0d6cb46e9cd0008bdf3d3 😎 Browse the preview: https://deploy-preview-11009--vector-project.netlify.app |
github-actions
bot
added
domain: core
Soak Test ResultsBaseline: 573cda3 ExplanationA soak test is an integrated performance test for vector in a repeatable rig, with varying configuration for vector. What follows is a statistical summary of a brief vector run for each configuration across SHAs given above. The goal of these tests are to determine, quickly, if vector performance is changed and to what degree by a pull request. Test units below are bytes/second/CPU, except for "skewness". The further "skewness" is from 0.0 the more indication that vector lacks consistency in behavior, making predictions of fitness in the field challenging. The abbreviated table below, if present, lists those experiments that have experienced a statistically significant change in their throughput performance between baseline and comparision SHAs, with 90.0% confidence. Negative values mean that baseline is faster, positive comparison. Results that do not exhibit more than a ±8.87% change in mean throughput are discarded. The abbreviated table will be omitted if no statistically interesting changes are observed. No statistically interesting changes with confidence 90.00%. Fine details of change detection per experiment.
Fine details of each soak run.
|
|
Since writing the initial commit I've created two offwaketime profiles:
The profile does look better: the main offwake in the fanout is now BTree clone. Top-of-line throughput is not changed, of course. I'll re-run the soak when #10923 goes in so we have data about variance. |
blt
force-pushed
the
tokio_channels_not_futures
branch
2 times, most recently
from
342a2d8
to
9624ebe
Compare
tobz
approved these changes
Jan 25, 2022
Once #10923 is merged up the soak infra changes will disappear from here. I really wanted to capture variance data. Forgot to, uh, call out that I'd done a goofy thing. :) |
Soak Test ResultsBaseline: 075328e ExplanationA soak test is an integrated performance test for vector in a repeatable rig, with varying configuration for vector. What follows is a statistical summary of a brief vector run for each configuration across SHAs given above. The goal of these tests are to determine, quickly, if vector performance is changed and to what degree by a pull request. Where appropriate units are scaled per-core. The table below, if present, lists those experiments that have experienced a statistically significant change in their throughput performance between baseline and comparision SHAs, with 90.0% confidence OR have been detected as newly erratic. Negative values mean that baseline is faster, positive comparison. Results that do not exhibit more than a ±8.87% change in mean throughput are discarded. An experiment is erratic if its coefficient of variation is greater than 0.3. The abbreviated table will be omitted if no interesting changes are observed. No interesting changes with confidence ≥ 90.00%: Fine details of change detection per experiment.
Fine details of each soak run.
|
After running a [offwaketime](https://github.com/iovisor/bcc/blob/master/tools/offwaketime.py) profile over vector running `http_pipeline_blackhole` I found that we were off-cpu non-trivially because of blocks sending into the futures channel. I'm unsure if this is improved as I write this commit but I'm going to send it up to CI for soaking. I do know that, theoretically, the tokio channel plays better with the tokio runtime compared to futures. REF #11006 Signed-off-by: Brian L. Troutwine <brian@troutwine.us>
blt
force-pushed
the
tokio_channels_not_futures
branch
from
9624ebe
to
5a3325e
Compare
|
Catching up here, but wanted to note that what was changed here was just the control channel, not the actual data plane that events flow through. That channel is only used on config reloads, so it makes sense that there would be essentially no change in performance here. Still, 👍 to standardizing on tokio channels. |
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.
After running a offwaketime profile over vector running
http_pipeline_blackholeI found that we wereoff-cpu non-trivially because of blocks sending into the futures channel. I'm
unsure if this is improved as I write this commit but I'm going to send it up to
CI for soaking. I do know that, theoretically, the tokio channel plays better
with the tokio runtime compared to futures.
REF #11006
Signed-off-by: Brian L. Troutwine brian@troutwine.us