[SERVER-36458] Investigate microbenchmark regression with timestamp safe unique indexes Created: 06/Aug/18 Updated: 27/Aug/18 Resolved: 27/Aug/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Sulabh Mahajan | Assignee: | Brian Lane |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Sprint: | Storage Engines 2018-08-13 | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 0 | ||||||||||||
| Description |
|
To measure performance impact due to introduction of timestamp safe unique indexes we added microbenchmarks targetting the unique indexes with Initial run of the microbenchmarks show some regression. This ticket is to investigate that. |
| Comments |
| Comment by Brian Lane [ 27/Aug/18 ] | |||||||||||||||||||||||
|
Based on the comments - looks good to close this one. | |||||||||||||||||||||||
| Comment by Asya Kamsky [ 13/Aug/18 ] | |||||||||||||||||||||||
|
sulabh.mahajan thanks for clarification. This seems reasonable to me given the work that was done. I don’t think we should prioritize this over other work we are currently doing. | |||||||||||||||||||||||
| Comment by Sulabh Mahajan [ 13/Aug/18 ] | |||||||||||||||||||||||
|
asya, Also degradation is somewhat less pronounced when replication is enabled. eg for insert on standalone vs 1-node replset:
| |||||||||||||||||||||||
| Comment by Asya Kamsky [ 10/Aug/18 ] | |||||||||||||||||||||||
|
The degradation would be presumably same 10% for every unique index in the collection, is that right? Just to make sure I'm understanding this correctly, this applies to _id index as well as any other unique index?
| |||||||||||||||||||||||
| Comment by Alexander Gorrod [ 10/Aug/18 ] | |||||||||||||||||||||||
|
asya and brian.lane: The change to allow unique indexes to behave correctly regards timestamp reads showed a performance regression on some microbenchmarks as described in this ticket. Can you help us to decide whether to put effort into general performance tuning in order to try to recover the performance difference? | |||||||||||||||||||||||
| Comment by Sulabh Mahajan [ 09/Aug/18 ] | |||||||||||||||||||||||
|
Insert is slower because the new unique index inserts and removes a prefix key to make sure that nothing in parallel adds a duplicate entry. This is an extra bit of work being done with the new indexes. On disabling the responsible code I get back the performance. The relevant code is:
The test for removing entries from the index is scripted to remove and re-insert entries. So the regression there is from the insertion itself. On disabling the above code, similar to in insert, I was also able to get back performance. | |||||||||||||||||||||||
| Comment by Henrik Ingo (Inactive) [ 07/Aug/18 ] | |||||||||||||||||||||||
|
Wow you were fast! I created and linked a BF ticket now. |