Asp.net request queued in IIS even with low traffic and CPU usage is low (CPU:40%,: 50req/sec,20 concurrent users)

Question

I am making some stress tests on a Asp.Net WebApi (.Net 4.7.2 with IIS 10 on a Windows 2019 server/ 8CPU core) and I observe that most of the request seemed to be queued even with a low traffic. The average response time of the api is of 300 ms. Here are the http request that I see in debudiag :

HttpContext Report

HttpContext Timeout Completed RunningSince ThreadId ReturnCode Verb             RequestPath+QueryString 
65ac4d8 110 Sec     Yes     ---         200 POST                /WS_TEST/Orders/Aborted  
65aea9c 110 Sec     Yes     ---         200 POST                /WS_TEST/Orders/Aborted  
66bf520 110 Sec     Yes     ---         200 POST                /WS_TEST/Orders/Aborted  
6b256ec 110 Sec     No  2 Sec 56    200 POST                /WS_TEST/Orders/Aborted  
8506498 110 Sec     Yes     ---         200 POST                /WS_TEST/Orders/Aborted  
a5b81ec 110 Sec     Yes     ---         200 POST                /WS_TEST/Orders/Aborted  
a752e98 110 Sec     Yes     ---         200 POST                /WS_TEST/Orders/Aborted  
c64d35c 110 Sec     Yes     ---         200 POST                /WS_TEST/Orders/Aborted  
c843028 110 Sec     Yes     ---         200 POST                /WS_TEST/Orders/Aborted  
e562f54 110 Sec     Yes     ---         200 POST                /WS_TEST/Orders/Aborted  
e901974 110 Sec     Yes     ---         200 POST                /WS_TEST/Orders/Aborted  
108cc6fc 110 Sec    Yes     ---         200 POST                /WS_TEST/Orders/Aborted  
126159c4 110 Sec    Yes     ---         200 POST                /WS_TEST/Orders/Aborted  
12c08d94 110 Sec    No  2 Sec 61    200 POST                /WS_TEST/Orders/Aborted  
1464e364 110 Sec    Yes     ---         200 POST                /WS_TEST/Orders/Aborted  
147b4488 110 Sec    No 2 Sec 41         200 POST                /WS_TEST/Orders/Aborted  

Here is what windbg give me for the threadpool stats :

0:000> !threadpool
CPU utilization: 48%
Worker Thread: Total: 27 Running: 6 Idle: 17 MaxLimit: 8191 MinLimit: 8
Work Request in Queue: 0

In my load test I have a client with 20 threads running always the same requests in a loop, so I expect to see the CPU doing some more work as there should be always 20 request pending (I have no pause in my client script). But it's not seems to be the case.. After analyzing a lot of dumps , a strange thing that I noticed : I just see at anytime at max 3 to 5 request seems to be handled concurrently.

I do not see any threads blocked or waiting after a synchronization. So what could be the cause of this behavior?
The default threadpool configuration ? What should I check next ?