# Default-blocking-io-dispatcher in Akka HTTP **URL:** \ **Category:** Akka HTTP\ **Tags:** akka-http\ **Created:** [February 28, 2020, 3:11am UTC](https://discuss.akka.io/t/default-blocking-io-dispatcher-in-akka-http/6020 "2020-02-28T03:11:41Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![eugenemiretsky](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.akka.io/eugenemiretsky/32/1508_2.png) [@eugenemiretsky](https://discuss.akka.io/u/eugenemiretsky)\ **Post date:** [February 28, 2020, 3:11am UTC](https://discuss.akka.io/t/default-blocking-io-dispatcher-in-akka-http/6020/1 "2020-02-28T03:11:41Z")
Hi, We run a pretty simple remote actor in an Akka cluster. There are 4 actors that get a request, make an HTTP call using Akka Http, do very basic map on the response, and return it. The system is receiving 20k TPS, and we need 20 2cpu container to run it, which seems like too much. 1. Thread dump shows 2 of default-blocking-io-dispatcher-142/141 threads: Where could they be coming from? The blocking-io-dispatcher is part of Akka Stream, but we don’t use it anywhere explicitly, nor make any blocking calls 2. How would you recommend to tune the thread pools? Right now I am using default dispatcher for the actors, and ExecutionContext.Implicits.global for the future operations (simple maps). And I see 24 .default-dispatcher threads 3. What’s the best way to avoid context switching on the map operations? was thinking to use FastFuture, a Trampoline execution context, or [https://github.com/kamon-io/Kamon/blob/master/kamon-core/src/main/scala/kamon/util/CallingThreadExecutionContext.scala](https://github.com/kamon-io/Kamon/blob/master/kamon-core/src/main/scala/kamon/util/CallingThreadExecutionContext.scala) ---
**Author:** ![jrudolph](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.akka.io/jrudolph/32/80_2.png) [@jrudolph](https://discuss.akka.io/u/jrudolph)\ **Post date:** [March 11, 2020, 10:56am UTC](https://discuss.akka.io/t/default-blocking-io-dispatcher-in-akka-http/6020/2 "2020-03-11T10:56:21Z")
Hi @eugenemiretsky, I would do some profiling to find what’s going on. The number of threads definitely looks too high if each container only gets 2 cpu. You should probably also use the default dispatcher for the Future use cases and also strip down the amount of threads on the default dispatcher. The ForkJoinPool backing `Implicits.global` and Akka’s default dispatcher is known to have some overhead while spinning to wait for new tasks. In a CPU constrained scenario you should be fine with the number of threads being equal the number of cores available. Johannes ---
**Author:** ![eugenemiretsky](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.akka.io/eugenemiretsky/32/1508_2.png) [@eugenemiretsky](https://discuss.akka.io/u/eugenemiretsky)\ **Post date:** [March 31, 2020, 1:11am UTC](https://discuss.akka.io/t/default-blocking-io-dispatcher-in-akka-http/6020/3 "2020-03-31T01:11:10Z")
Would you recommend using Affinity dispatcher, or Pinned dispatcher for each actor? We have an actor per CPU core, and as I mentioned, no blocking operation ---
**Author:** ![jrudolph](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.akka.io/jrudolph/32/80_2.png) [@jrudolph](https://discuss.akka.io/u/jrudolph)\ **Post date:** [April 16, 2020, 1:01pm UTC](https://discuss.akka.io/t/default-blocking-io-dispatcher-in-akka-http/6020/4 "2020-04-16T13:01:29Z")
No, usually using the fork-join-executor will give you best latency and throughput. ---
**Author:** ![eugenemiretsky](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.akka.io/eugenemiretsky/32/1508_2.png) [@eugenemiretsky](https://discuss.akka.io/u/eugenemiretsky)\ **Post date:** [April 26, 2020, 7:36pm UTC](https://discuss.akka.io/t/default-blocking-io-dispatcher-in-akka-http/6020/5 "2020-04-26T19:36:54Z")
@jrudolph Having a somewhat similar issue here - don’t seem to be able to tune the client to get good performance. > [@1000+ actors with Akka Http Client](https://discuss.akka.io/t/1000-actors-with-akka-http-client/6358): > > Hey, We are running an application that reads from s3 and makes POST HTTP calls. We are able to get around 2k TPS with another client, but cannot get more than 500 with Akka HTTP. We are also seeing 1000s of actors being created. At some point we had as many as 15K. Is the number of actors expected? Tried to see if the client is creating an actor per request, but couldn’t find anything If it is not expect, what kind of config/code error can lead to that? Akka Http version: 10.1.10 Akka ve…