[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:
Depends
Duplicate
is duplicated by SERVER-73456 Evaluate feasibility of rate limiting... Closed
Related
related to SERVER-81541 Complete TODO listed in SERVER-80006 Closed
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!

Generated at Thu Feb 08 06:42:28 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.