[SERVER-80006] Investigate best lock for holding the rate limiter mutex Created: 15/Aug/23 Updated: 28/Sep/23 Resolved: 28/Sep/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Maddie Zechar | Assignee: | Backlog - Query Integration |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Assigned Teams: |
Query Integration
|
||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
We are still discussing if we want to continue to use the current sliding window rate limiter or reconfigure to use sharding's queryAnalysis token bucket rate limiter. If we indeed continue to use the former, we should investigate which type of lock gives the best performance. We should use the google micro benchmark (rate_limiting_bm.cpp) and also flamegraphs to determine the performance of stdx::unique_lock, stdx::lock_guard or something lock free (William's idea). |
| Comments |
| Comment by Charlie Swanson [ 28/Sep/23 ] |
|
Closing this ticket out as "Won't Do", since I believe it is non-trivial and also low-value. The rate limiting performance is pretty solid and based on my understanding this will only possibly provide incremental benefits. Please comment if you'd like to see this happen! |