[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: |
|
||||||||||||||||
| 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. 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_WTThis commit (and the ones before it) take 39 minutes Windows 2008R2 DEBUGSame thing: |
| Comments |
| Comment by Jonathan Reams [ 01/Feb/16 ] |
| 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: |
| 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: |
| 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": |