How to configure ThreadPool priority in Playframew

2019-05-14 05:20发布

问题:

We have 2 ExecutionContexts in the system (Scala 2.11.4, Playframework 2.3.7)

  1. Primary context - for system operational work (Uses primary Play ExecutionContext).
  2. Administrative - for backend related tasks.

I've separated those into 2 in application.configurations.

play {
  akka {
    akka.loggers = ["akka.event.slf4j.Slf4jLogger"]
    loglevel = DEBUG
    actor {
      default-dispatcher = {
        fork-join-executor {
          parallelism-min = 20
          parallelism-max = 20
        }
      }
    }
  }
}

contexts {
  admin {
    fork-join-executor {
      parallelism-min = 30
      parallelism-max = 30
    }
  }
}

Is there a way to configure ThreadPool priority?

回答1:

There is currently no way to configure thread priority because that setting is mostly without effect on many platforms and as such qualifies as a placebo. If you start and actively use more threads than you have CPU cores then the resulting competition will be costly and will waste resources, so you will be better off carefully fitting your threadpool sizes to the available cores for the CPU-bound part.

The posted configuration example makes me wonder: does the system really have more than 30 cores? Otherwise the contexts.admin dispatcher would not be able to profit from prioritization anyway.

In the end there is only exactly one way to reserve CPU time for a specific task, and that is to never give those cores to any other task (there would be other ways if you were writing low-level C code and using Unix realtime priorities, but that is error-prone and not for the faint of heart—making a mistake will lock you out of the system).

This means that on a system with 24 cores that is supposed to handle some network traffic, talk to some DB and crunch some numbers, I would for example create a fixed threadpool of size 16 for the number crunching and a threadpool for the blocking DB calls (sized according to the number of connections that works best for that DB, say 40) plus the normal dispatchers for Play and Akka that handle the network and miscellaneous other stuff (that is neither blocking nor CPU intensive). Thread priorities do not factor into this picture.