[SERVER-31972] Reduce the number of iterations for the toggle_feature_compatibility.js workload Created: 15/Nov/17 Updated: 30/Oct/23 Resolved: 29/Nov/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.2, 3.7.1 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Eddie Louie | Assignee: | Eddie Louie |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Backport Requested: |
v3.6
|
||||||||||||||||||||
| Sprint: | TIG 2017-12-04 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||||||
| Description |
|
In the stepdown suites, concurrency_sharded_with_stepdowns and concurrency_sharded_with_stepdowns_and_balancer, the toggle_feature_compatibility.js workload is initialized to run for 5000 iterations which frequently times out the suites on the Windows DEBUG build variant after 6hrs. It was also found that this workload with the stepdown configuration causes spurious failures, and hence was blacklisted with For other suites, like concurrency_sharded* we are going to reduce the number of iterations this workload is run so it will finish in a reasonable time. |
| Comments |
| Comment by Githook User [ 03/Jan/18 ] |
|
Author: {'name': 'Eddie Louie', 'username': 'elouie99', 'email': 'eddie.louie@mongodb.com'}Message: (cherry picked from commit 6dec00d69b65ff1c9cc92ba9aed5f39ca207cb86) |
| Comment by Githook User [ 29/Nov/17 ] |
|
Author: {'name': 'Eddie Louie', 'username': 'elouie99', 'email': 'eddie.louie@mongodb.com'}Message: |
| Comment by Esha Maharishi (Inactive) [ 16/Nov/17 ] |
|
kaloian.manassiev, I'm assigning |
| Comment by Max Hirschhorn [ 16/Nov/17 ] |
|
justin.seyster, we don't have a good way of targeting the toggle_feature_compatibility.js FSM workload just on the Windows 2008R2 DEBUG build variant. We would need to change the number of iterations altogether or blacklist the FSM workload altogether.
It's interesting you bring that up because the concurrency framework runs the "dropDatabase" command after each FSM workload. However, after talking with esha.maharishi, it appears that we still keep the entries in the config.collections collection. It looks like |
| Comment by Justin Seyster [ 16/Nov/17 ] |
|
Unfortunately, 80 iterations is not enough to trigger the failure that toggle_feature_compatibility.js was originally intended to test. Maybe we should just disable this test for the Windows DEBUG variant. We might be able to speed up the test. I don't have metrics right now to confirm this, but I think that the biggest time sink is adding/removing collection UUIDs whenever we raise/lower the feature compatibility version. max.hirschhorn, do collections from other FSM workloads stick around after the workloads finish, and could we safely delete them when this workload starts? Having fewer collections might speed up this workload a lot. |
| Comment by Eddie Louie [ 16/Nov/17 ] |
|
Testing this workload on the concurrency_sharded suite with 5000 iterations took about 2hrs. About 1.5 sec per iteration. To keep this around 2mins, we can set it to about 80 iterations. |