[SERVER-19983] Performance Regression in Mongo-perf Commands.DistinctWithIndexAndQuery Created: 14/Aug/15 Updated: 19/Sep/15 Resolved: 18/Aug/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 3.1.7 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | David Daly | Assignee: | David Storch |
| Resolution: | Done | Votes: | 0 |
| Labels: | mpreg | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | QuInt 8 08/28/15 | ||||||||
| Participants: | |||||||||
| Description |
|
Seeing a regression on wiredTiger and MMAPv1 on Commands.DistinctWithIndexAndQuery on evergreen. MMAPv1 results Regression starts on commit: f9904bc To recreate with mongo-perf:
To recreate with the mongo shell:
|
| Comments |
| Comment by Githook User [ 18/Aug/15 ] | ||||||
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: | ||||||
| Comment by David Daly [ 17/Aug/15 ] | ||||||
|
Yeah, 1% is definitely within error at this point. | ||||||
| Comment by David Storch [ 17/Aug/15 ] | ||||||
|
Thanks David. To get back the 3.6%, we can just move the expensive call so that it will get called for explain, but will not get called for a regular (not explained) distinct command. As for the remaining ~1%, is this within the bounds of error for perf patch builds? I didn't see anything else in the patch that looked suspect. | ||||||
| Comment by David Daly [ 17/Aug/15 ] | ||||||
|
That patch got a 3.63% performance improvement, which is most of the 4-5% regression we saw. | ||||||
| Comment by David Daly [ 14/Aug/15 ] | ||||||
|
Patch build here: https://evergreen.mongodb.com/version/55ce111b3ff1221da80002a9_0 | ||||||
| Comment by David Daly [ 14/Aug/15 ] | ||||||
|
Thanks david.storch. Sounds like a good experiment. Will set it up and see what it shows. | ||||||
| Comment by David Storch [ 14/Aug/15 ] | ||||||
|
I'm surprised that there would be any noticeable performance difference associated with this change. If I'm not mistaken, this is the only part of that change which is exercised by the test:
Nothing here should be too expensive, though if I was going to point the finger at any of these calls it would be _params.bounds.toBSON(). I recommend running a perf patch build with that line commented out to see if that makes the regression go away. |