Each of the six runs ramps up from 0 to 500 client threads each attempting to do as many as 1000 updates per second. The system reaches CPU saturation at about 38 k/s, so of course we expect to see queuing, and to see the client open 500 connections. The six runs are respectively
- synchronous, 3.5.11
- synchronous, 3.5.11 +
- synchronous, 3.5.11 with calls to markThreadIdle suppressed
- adaptive, 3.5.11
- adaptive, 3.5.11 +
- adaptive, 3.5.11 with calls to markThreadIdle suppressed
Comparing runs 4, 5, and 6 we see the impact of markThreadIdle in 4 with the adaptive service executor, fixed by either change in 5 and 6.
Once the current performance issue with markThreadIdle has been addressed by
SERVER-28599, we should investigate whether and where markThreadIdle should be called in the adaptive case. This should be evaluated using the tests from SERVER-16773 that led to the implementation of markThreadIdle for the synchronous case.