-
Notifications
You must be signed in to change notification settings - Fork 553
test(shared-tree): Remove the report output path to let the benchmark tool to post it to pipeline #25022
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR removes a specific output directory configuration for memory usage benchmarks to allow the benchmark tool to use its default path and publish results to pipeline artifacts automatically.
- Removes the hardcoded
reportDir
reporter option from the Mocha configuration - Allows the benchmark tool to handle report output path management internally
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Chatted offline; the change looks fine as far as I can tell but we'd like to see a successful run of the e2e tests pipeline with it before merging so I asked @chentong7 to do a manual run form a test/
branch.
… tool to post it to pipeline
Still waiting for Build - client packages run: https://dev.azure.com/fluidframework/internal/_build/results?buildId=347013&view=results |
Finally, benchmark pipeline run: https://dev.azure.com/fluidframework/internal/_build/results?buildId=347037&view=results |
@@ -129,7 +129,7 @@ | |||
"test:customBenchmarks": "mocha --config ./.mocharc.customBenchmarks.cjs", | |||
"test:customBenchmarks:verbose": "cross-env FLUID_TEST_VERBOSE=1 npm run test:customBenchmarks", | |||
"test:memory": "mocha --perfMode --config ./src/test/memory/.mocharc.cjs", | |||
"test:memory-profiling:report": "mocha --config ./src/test/memory/.mocharc.cjs", | |||
"test:memory-profiling:report": "mocha --perfMode --config ./src/test/memory/.mocharc.cjs", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For reference: benchmarks always need the --perfMode
flag to execute as such (and not as correctness unit tests). This missing one was an oversight from the past.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Include it in the PR description
@@ -22,6 +22,7 @@ const extendedConfig = { | |||
"node-option": [...baseNodeOptions, "expose-gc", "gc-global", "unhandled-rejections=strict"], // without leading "--" | |||
"reporter": "@fluid-tools/benchmark/dist/MochaReporter.js", | |||
"reporterOptions": ["reportDir=.memoryTestsOutput/"], | |||
"timeout": "90000", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@chentong7 I believe you confirmed we can use a much lower timeout, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And it timed out at the end. Instead of making a flaky test, slow test is more acceptable.
Error: Timeout of 80000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
80000 or 8000? If we have individual tests that are really taking 80s when run as benchmarks, we might need to rethink our strategy for them :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, it's worse than 80s. Each test case goes 30s makes the total test set to 90s, and some old test cases just running forever.
Overall summary
status suite name # of passed tests total time (s)
------ ---------------------------------------------------------------------------------- ----------------- --------------
✔ SharedTree table APIs memory usage Column Insertion 3 out of 3 90.1
✔ SharedTree table APIs memory usage Row Insertion 3 out of 3 90.1
✔ SharedTree table APIs memory usage Column and Row Insertion 2 out of 2 60.1
✔ SharedTree table APIs memory usage Column Insertion 3 out of 3 90.1
✔ SharedTree table APIs memory usage Row Insertion 3 out of 3 85.2
✔ SharedTree table APIs memory usage Column and Row Insertion 2 out of 2 38.9
✔ SharedTree table APIs memory usage Column Removal 2 out of 2 60.1
✔ SharedTree table APIs memory usage Row Removal 3 out of 3 82.8
✔ SharedTree table APIs memory usage Column and Row Removal 2 out of 2 60.1
✔ SharedTree table APIs memory usage Insert a column and a row and remove right away 1 out of 1 30.1
✔ SharedTree table APIs memory usage Cell Value Setting 3 out of 3 89.0
✔ SharedTree table APIs memory usage Column Insertion 3 out of 3 71.9
✔ SharedTree table APIs memory usage Row Insertion 3 out of 3 68.8
✔ SharedTree table APIs memory usage Column and Row Insertion 2 out of 2 41.2
✔ SharedTree table APIs memory usage Column Insertion 3 out of 3 70.7
✔ SharedTree table APIs memory usage Row Insertion 3 out of 3 70.8
✔ SharedTree table APIs memory usage Column and Row Insertion 2 out of 2 39.8
✔ SharedTree table APIs memory usage Column Removal 2 out of 2 45.1
✔ SharedTree table APIs memory usage Row Removal 3 out of 3 73.2
✔ SharedTree table APIs memory usage Column and Row Removal 2 out of 2 47.9
✔ SharedTree table APIs memory usage Insert a column and a row and remove right away 1 out of 1 16.6
✔ SharedTree table APIs memory usage Cell Value Setting 3 out of 3 68.4
✔ SharedTree table APIs memory usage Column Removal 2 out of 2 43.0
✔ SharedTree table APIs memory usage Row Removal 3 out of 3 70.8
✔ SharedTree table APIs memory usage Column and Row Removal 2 out of 2 47.1
✔ SharedTree table APIs memory usage Insert a column and a row and remove right away 1 out of 1 20.9
✔ SharedTree table APIs memory usage Cell Value Setting 3 out of 3 69.5
✔ SharedTree memory usage Forest memory usage Array of monomorphic leaves 8 out of 8 840.6
✔ SharedTree memory usage Forest memory usage Array of polymorphic leaves 8 out of 8 837.8
✔ SharedTree memory usage Forest memory usage Array of deep monomorphic leaves 8 out of 8 1,016.4
! SharedTree memory usage 4 out of 10 120.8
total 93 out of 99 4,458.2
This @fluidframework-tree test step itself just goes over 1.5h
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pending confirmation from a manual run of the pipeline, this looks good to me. Just update the timeout to the lower value that you tested with.
Run memory usage tests - @fluidframework/tree pipeline step goes over 1h: https://dev.azure.com/fluidframework/internal/_build/results?buildId=347037&view=logs&j=12bb9097-5cdf-5833-9679-3c0d8d960191&t=9d111fa8-556a-5c73-2a6e-ed547ec5ff4f |
Run memory usage tests - @fluidframework/tree pipeline step goes over 1.5h: https://dev.azure.com/fluidframework/internal/_build/results?buildId=347069&view=logs&j=12bb9097-5cdf-5833-9679-3c0d8d960191&t=0e0d0841-03e8-5a8c-1611-e689df253089 |
@chentong7 how do local runs look? How long do they take to complete? |
Yes, each test case takes 30s to complete. I put my local timeout to 5mins and it last ~1h for 10 times test cases and hours(like before bed) for 100 times. I disable the old tests first because some old tests is just forever long: |
Sync-up with Josh offline, we shouldn't enable this long running test package in pipeline. Pipeline jobs can be run in parallel. Open a task to modify this pipeline to multi-job mode then come back to it to enable tree package in benchmark pipeline. |
Remove memory usage report specific output path to let the benchmark tool to generate report on a default path and it will be published to pipeline artifacts. Benchmarks always need the --perfMode flag to execute as such (and not as correctness unit tests). This missing one was an oversight from the past. Adding it.