fix(tests): Use one more thread for merge_and_fork test #11112
Merged
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
I'm really not sure why this works, but it appears to fix the issue we saw with this test starting to fail on Linux after the upgrade to Tokio 1.16.1. Signed-off-by: Jesse Szwedko <jesse@szwedko.me>
|
✔️ Deploy Preview for vector-project canceled. 🔨 Explore the source changes: 258a9c0 🔍 Inspect the deploy log: https://app.netlify.com/sites/vector-project/deploys/61f832f6d674470008c77a08 |
spencergilbert
approved these changes
Jan 31, 2022
|
The comment still references "two" threads. On the whole I'm not really sure what this test is demonstrating and would move to strike it if no one else has a more clear idea. It's very, uh, integration test-y without being an integration test? If we're trying to show something important about the topology surely there's a less indirect way to demonstrate whatever it is this is doing and if we're testing something about tokio that's inappropriate. I think this test is trying to establish we don't drop data during shutdown? But it's using no synchronization to ensure the test itself doesn't get ahead of the underlying topology tasks? |
Signed-off-by: Jesse Szwedko <jesse@szwedko.me>
Doh, I updated the comment. 258a9c0
It looks to me just like a high level integration test. I imagine the components of this are tested at various levels, but do see some value in having basic end-to-end integration tests. It looks like it was originally added very early on in Vector's lifetime though (876a097), so it is very possible it has outlived its purpose. I'll defer to you and others that are closer to the code to decide if it (or any tests in |
Oh wow, ancient. For what it's worth this test strikes me as both indirect in what it's establishing and very precise in the results it is looking for, which is a bad combo. I'd strike it, me, or mark it as allow-to-fail and then setup a task to extract this into a proper integration test. |
Soak Test ResultsBaseline: f5e8e5d 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.
|
jszwedko
added a commit
that referenced
this pull request
Feb 1, 2022
Prompted by #11112 (comment) I don't really have a strong opinion here, so opening up to solicit others. Does anyone see value in these tests? Or do we think we have sufficient coverage already of the behavior here? These tests were introduced very early on in Vector's history, so it seems plausible that they may have outlived their usefullness. The `merge_and_fork` one, in particular, has shown up as flakey in the past. Signed-off-by: Jesse Szwedko <jesse@szwedko.me>
jszwedko
added a commit
that referenced
this pull request
Feb 2, 2022
Prompted by #11112 (comment) I don't really have a strong opinion here, so opening up to solicit others. Does anyone see value in these tests? Or do we think we have sufficient coverage already of the behavior here? These tests were introduced very early on in Vector's history, so it seems plausible that they may have outlived their usefullness. The `merge_and_fork` one, in particular, has shown up as flakey in the past. Signed-off-by: Jesse Szwedko <jesse@szwedko.me>
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.
I'm really not sure why this works, but it appears to fix the issue we
saw with this test starting to fail on Linux after the upgrade to Tokio
1.16.1.
I'm guessing this is due to the multi-threaded scheduler changes mentioned here: tokio-rs/tokio#4383
Signed-off-by: Jesse Szwedko jesse@szwedko.me