[SERVER-22077] Improve the runtime of sharding js tests Created: 29/Dec/15  Updated: 06/Dec/22  Resolved: 30/Nov/16

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Ian Whalen (Inactive) Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Duplicate
Related
is related to SERVER-22748 NetworkInterfaceASIO opens new connec... Closed
Assigned Teams:
Sharding
Backwards Compatibility: Fully Compatible
Sprint: Sharding E (01/08/16)
Participants:
Linked BF Score: 0

 Description   

UPDATE: In the interest of not declaring implementation, I just wanted to highlight that the goal here is twofold:

1) Reducing the number of failures showing up for the buildbaron.
2) Taking scheduled->finish patch build execution time below 2.5 hours.

How we get there (splitting test suites, deleting tests, running in parallel, etc.) I leave to whomever owns this.

===========

I'm not certain this is even the place to discuss this, but wanted to at least start the discussion. We've noticed a few jumps in test timing, and it seems like we should at least consider reducing those jumps where possible. This ticket just represents the first test timing regression that I've run down.

Enterprise RHEL 6.2 - sharding_WT

This commit (and the ones before it) take 39 minutes
This commit takes 48 minutes
I’m rerunning them now, but it looks like one of these two commits by Kal caused
mongos_rs_shard_failure_tolerance.js to go from 1 minutes to 8 minutes.
https://evergreen.mongodb.com/task/mongodb_mongo_master_enterprise_rhel_62_64_bit_sharding_WT_a707b9852bf6e03e7d6e6ef3ad464dbd28d690fa_15_11_11_15_18_34
https://evergreen.mongodb.com/task/mongodb_mongo_master_enterprise_rhel_62_64_bit_sharding_WT_67b68b5f094d88753ae2fe14f6d708c9e5b4bfbd_15_11_11_15_18_34

Windows 2008R2 DEBUG

Same thing:
The first commit (and the ones before it) take 3 hours and 10 minutes
The second commit takes 4 hours.
Looks like one of those two commits increased the timing for several tests within the suite.



 Comments   
Comment by Jonathan Reams [ 01/Feb/16 ]

again:
https://evergreen.mongodb.com/task/mongodb_mongo_v3.2_osx_108_sharding_fa6424b9326600083d07d099a52466e7e02eb45f_16_01_29_21_22_52

https://evergreen.mongodb.com/task/mongodb_mongo_master_osx_108_ssl_sharding_WT_3e41f72b36656a58f28fea3314e50aa7dcac47c9_16_01_29_23_14_38

https://evergreen.mongodb.com/task/mongodb_mongo_v3.2_osx_108_sharding_WT_0f10a675edbb6aa9c823bb8bf9f9b20027fea01f_16_01_29_19_50_15

https://evergreen.mongodb.com/task/mongodb_mongo_v3.2_osx_108_sharding_0f10a675edbb6aa9c823bb8bf9f9b20027fea01f_16_01_29_19_50_15

Comment by Githook User [ 14/Jan/16 ]

Author:

{u'username': u'kaloianm', u'name': u'Kaloian Manassiev', u'email': u'kaloian.manassiev@mongodb.com'}

Message: SERVER-22077 Speed up sharding tests which stop replica set members
Branch: v3.2
https://github.com/mongodb/mongo/commit/abbd286fba6ebffe874b182ebbd4b1dbd8de0ba4

Comment by Githook User [ 11/Jan/16 ]

Author:

{u'username': u'kaloianm', u'name': u'Kaloian Manassiev', u'email': u'kaloian.manassiev@mongodb.com'}

Message: SERVER-22077 Speed up sharding tests which stop replica set members
Branch: master
https://github.com/mongodb/mongo/commit/53da3358ef85f008227f32770ae978537790f8e7

Comment by Ian Whalen (Inactive) [ 30/Dec/15 ]

I should add that this jump in test time also seems to be responsible for having finally pushed the OS X buildvariants up to the limit of their task execution time (6 hours) which is resulting in spurious "failures":

https://evergreen.mongodb.com/task_timing/mongodb-mongo-master#/project=mongodb-mongo-master&buildVariant=osx-108-debug&taskName=sharding&requester=gitter_request&limit=200

Generated at Thu Feb 08 03:59:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.