[SERVER-20831] sharding test suite slowness Created: 08/Oct/15 Updated: 14/Apr/16 Resolved: 13/Oct/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Eric Milkie | Assignee: | Siyuan Zhou |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Sprint: | Repl B (10/30/15) |
| Participants: |
| Description |
|
After a8e6c0ebc70fad95a5e05281076cfa4b6db500c2 commit, the sharding suite got slower instead of the expected increase in speed. |
| Comments |
| Comment by Siyuan Zhou [ 13/Oct/15 ] |
|
milkie, OK, will resolve as "Cannot Reproduce". |
| Comment by Eric Milkie [ 13/Oct/15 ] |
|
Can this be resolved? The combination of the electionTimeout change plus the parallelization of the sharding suite has made it difficult to diagnose the slowness that was formerly present. Notably, even before those commits, I could not reproduce the slowness on my own machine, so I was beginning to suspect something specific to the builder that was running the tests (the slowness was only apparent on the generic "Linux 64"-flavored test runners.) |
| Comment by Eric Milkie [ 09/Oct/15 ] |
|
Can't reproduce the slowness on my machine. Siyuan will reevaluate after he pushes his change to reduce the default electionTimeout to 5 seconds. |