[SERVER-33723] Add command line parameter to Linkbench for writeConcern Created: 07/Mar/18 Updated: 06/Dec/22 Resolved: 03/Apr/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | William Schultz (Inactive) | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | Linkbench, gm-ack | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Sharding
|
||||
| Participants: | |||||
| Description |
|
To test transaction performance in a multi-node replica set, we would like to run Linkbench with transactions that commit at various write concerns (w:1 vs. w:majority). Currently, there is no way to explicitly configure Linkbench to do this. We should add a command line parameter that allows us to do this. |
| Comments |
| Comment by Henrik Ingo (Inactive) [ 22/Mar/19 ] |
|
The purpose of this ticket seems to be a bit in flux but... As william.schultz has brought up elsewhere, we don't run linkbench with w:majority at all. Certainly majority+snapshot should be the default, and then we should discuss whether lower durability and consistency are also relevant to test. It seems this is the ticket to review readConcern and writeConcern settings, but I can file a new separate ticket if you prefer. |
| Comment by Gregory McKeon (Inactive) [ 19/Jun/18 ] |
|
Leaving it up to sharding whether or not they want to do this when perf testing their optimization work. |
| Comment by James O'Leary [ 22/May/18 ] |
|
The linkbench driver now takes a connection url so a writeConcern is configurable (whether it is useful or not). |
| Comment by David Daly [ 15/Mar/18 ] |
|
I talked off-line with spencer about this. My understanding is the current concern is the replication performance on the secondary with regards to transactions. The experiment Spencer suggested would give the most actionable information on secondary performance here. I think we should do that. I'll open a ticket for that. I think running the existing tests with w:majority is also something we will want to do at some point as it will be more realistic of actual use. That said, it should be after the other tests. |
| Comment by William Schultz (Inactive) [ 13/Mar/18 ] |
|
If we don't think the configurability of writeConcern in Linkbench will ultimately be useful, then we may just want to close this ticket. |
| Comment by William Schultz (Inactive) [ 13/Mar/18 ] |
|
Using writeConcern as a way to measure secondary oplog application performance was an initial attempt to gather metrics. It may be too crude of a method to get accurate numbers. Perhaps we should chat about the best way to collect these kinds of metrics and if any changes need to be made to Linkbench or if the existing perf infrastructure will allow us to do this. |
| Comment by David Daly [ 13/Mar/18 ] |
|
spencer It's not clear to me from ticket and discussion the ultimate goal is right now. Could we chat in person tomorrow or Thursday? |
| Comment by Spencer Brody (Inactive) [ 13/Mar/18 ] |
|
I'm not convinced this is the best way to measure secondary performance in linkbench. I think we probably want to do something similar to the existing secondary application perf tests, where we block secondary application during the write load phase, then once the workload is complete turning on the secondary and seeing how long it takes to catch up. david.daly what do you think? |