[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:
Backports
Depends
Duplicate
is duplicated by SERVER-34478 Make shards in concurrency suite not ... Closed
Related
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 SERVER-31884.

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: SERVER-31972 Reduce the number of iterations for the toggle_feature_compatibility.js workload

(cherry picked from commit 6dec00d69b65ff1c9cc92ba9aed5f39ca207cb86)
Branch: v3.6
https://github.com/mongodb/mongo/commit/d6b8d447e900164341611cd34ac2fb69a1e87634

Comment by Githook User [ 29/Nov/17 ]

Author:

{'name': 'Eddie Louie', 'username': 'elouie99', 'email': 'eddie.louie@mongodb.com'}

Message: SERVER-31972 Reduce the number of iterations for the toggle_feature_compatibility.js workload
Branch: master
https://github.com/mongodb/mongo/commit/6dec00d69b65ff1c9cc92ba9aed5f39ca207cb86

Comment by Esha Maharishi (Inactive) [ 16/Nov/17 ]

kaloian.manassiev, I'm assigning SERVER-31865 to myself for this iteration, so we can unblacklist this workload from the stepdown suites. It should be very easy to do.

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.

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.

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 SERVER-31865 may be intended to changes this behavior, so perhaps that ticket is a different way to address the slowness of the toggle_feature_compatibility.js FSM workload. CC kaloian.manassiev

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.

Generated at Thu Feb 08 04:28:46 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.