When we developed the PriorityTicketHolder, we used the contention_ttl_deletions workload (see SERVER-72033) and mixed_genny_stress_with_scans workload to validate that workloads that send a mix of short-running queries with long-running scans benefit from the feature. The expectation is that the long-running queries are deprioritized, allowing for higher throughput of the short running queries and higher throughput overall. 

We haven't been able to reproduce those results with the Locust workload mixed_workloads_with_scans. Lets investigate the following: 

• Performance with the feature flag enabled/disabled on mixed_workload_with_scans and a fixed number of tickets, with execution control disabled
• Performance with the feature flag enabled/disabled on contention_ttl_deletes with fixed number of tickets and variable/EC enabled 

If there is no benefit of the feature, lets investigate if there is enough stress on the server, i.e. that it is deprioritizing the scans to the benefit of the short running queries, and make sure we understand the mix of queries the workload is sending.