[SERVER-77983] Investigate performance regressions in lookup and graph_lookup workloads with a config shard Created: 12/Jun/23 Updated: 12/Dec/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Wenqin Ye | Assignee: | Backlog - Cluster Scalability |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | sharding-nyc-subteam2 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Cluster Scalability
|
||||||||
| Participants: | |||||||||
| Story Points: | 5 | ||||||||
| Description |
|
As part of After some initial investigation, it was not immediately clear whether the regressions were due to issues with the test setup (where the config shard's setup was not the exact same as a regular shard server's) or if there are actual issues with the config shard code. This ticket should investigate the root cause of the observed performance regressions in the lookup and graph_lookup workloads and determine if it's a test setup issue or an issue with the config shard code. For reference, here were the results from Here is an example of the setup used for the genny workloads with a config shard:
|