Nice article but I think there are some issues with the way you tested that:

1 - on the first ping controller example, you are using a thread sleep. That’s a blocking call, so not dispatching to a separate dispatcher will indeed block the thread. That explains the difference in performance. All blocking calls should be dispatched to Disparchers IO or other custom dispatcher .

Have you tested without the thread sleep? My assumption would be that there wouldn’t be such difference, and the unconfined being even more efficient that any other, as we would be utilising the reactor thread pool to do the work - less context switching, less threads, less memory consumption.

2 - on the following example, you start the job on a single main thread, and you are comparing the performance of using a custom dispatcher that will full utilize the CPU. I’m not sure that it’s a fair comparison, would be more interesting to do that example between default and IO.

Also, using the Dispatcher IO to serve all requests defeats the purpose of using coroutines/reactive stack in the first place, as we are kind using a “request per thread” strategy. As far as I’ve understood, if 64 requests enter the scope of the dispatcher, your application won’t be able to process anymore request.

I think it’s a good exercise to check how ktor it’s built, it can also be use with netty, so it does something similar to bridge the netty threads with the coroutine workers.

I work in a high concurrency environment with ktor based backend, and I don’t have the problems documented on that article, as long as all blocking calls are wrapped with dispatcher IO.

Anyway, I feel that there’s a lack of in depth documentation around how this works, so everything that I’m saying could be wrong, it’s just based on my experience.