In the function `_performWaitForTicketUntil` in the ticketholder, we try to acquire a ticket in a loop. Logically, we would try the acquisition at the end of the loop since if we end up here, we already tried to acquire a ticket. However doing so slows down the loop and increase latency. This code is extremely sensitive to small changes.

Here's some sys-perf patches that shows this sensitivity to change, and the slowdown:

• https://spruce.mongodb.com/version/674f85eb3360e30007434bea/tasks?sorts=STATUS%3AASC%3BBASE_STATUS%3ADESC
• https://spruce.mongodb.com/version/674f8a018d242a00073f13a2/tasks?sorts=STATUS%3AASC%3BBASE_STATUS%3ADESC
• https://spruce.mongodb.com/version/6750a2a10e762e00070641b9/tasks?sorts=STATUS%3AASC%3BBASE_STATUS%3ADESC

One hypothesis we have as to why this code is so sensitive to small change is that within the loop we check for cancellation using opCtx->checkForInterrupt(). This function calls a pure virtual function, then calls a function in the operation context. This could lead to load the opCtx in cache, displacing the cache for the acquisition loop. Also virtual calls are quite expensive. Since it looks like it's the only expensive operation in the body of the loop, it makes sense that it could be the cause for slowing it down.