SPM-4263 added a new execution control mechanism that when enabled sends some background tasks and operations that exceeds a dynamically set threshold of admissions to a new ticket pool with less access to the storage engine. This works well for the majority of scenarios, as short running operations have a higher number of tickets in the pool, allowing more operations with lower number of admissions access to the storage engine. However, if there is only one background operation (as can be seen with the perftest committed by PERF-7171) even though there might be a long queue of short running operations, this solely operation will always run, as it will always acquire a ticket.

On one side, this model prevents starvation of long running operations, and it prevents a single long running operation hoarding access to the storage engine when there are a lot of short running operations waiting. On the other side, it seems as it is violating the policy, as it seem to be cutting in the line of short running operations, because it is never waiting for a ticket. The purpose of this ticket is to investigate whether this is actually a problem in the model, and if it is, using the already committed perf test, POC some options to mitigate the issue. We could for example, in the ticketing system, once we determine an operation is long running, try to acquire a short running ticket, and once acquired, released it inmediately, and then try to acquire a long running ticket.