[SERVER-83981] Investigate configuring SyncServerOptions in gRPC Created: 07/Dec/23 Updated: 11/Dec/23 Resolved: 07/Dec/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Erin McNulty | Assignee: | Erin McNulty |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Service Arch 2023-12-11 |
| Participants: |
| Description |
|
When doing initial perf testing for gRPC, we saw that it spent a lot of time synchronizing the completion queue. We were curious if changing the gRPC SyncServerOptions might improve the performance-- investigate changing the number of completion queues and polling threads, and evaluate whether or not this improves the performance. |
| Comments |
| Comment by Erin McNulty [ 07/Dec/23 ] |
|
I made the SyncServerOptions a server parameter in my testing, and the results are summarized here. Note that the testing branch contains quite a few different changes, but the ones that explicitly note the sync server options are the only relevant ones. TLDR is that we didn't see any noticeable perf difference when changing the configurations-- when walking through the code I was not convinced that gRPC was actually using the different completion queues, even when they were provided. We concluded that changing the SyncServerOptions probably will not amount to any meaningful perf difference. |