Ignacio Perez
Ignacio Perez

Reputation: 2361

Play Framework does it threadpool scale when adding more resources to server

I am new to play and am using it for synchronous database calls and have a few things that I am unclear of or misconceptions; first of all in my application.conf I put in the following code

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

which I got from https://www.playframework.com/documentation/2.3.x/ThreadPools and also have read Play Framework and Threadpools . What this means is that you have at all times 300 threads available for blocking database actions? or 300 requests per second at max? also if I had more resources to the server like more Ram,CPU or cores does that increase the amount of threads available? For example if I buy a server that has 4 cores or etc.. would the available threads jump to 1,200 ? As stated before all my actions are blocking from user registration to user chats so trying to get my misconceptions out now before they become more costly.

Upvotes: 1

Views: 1100

Answers (1)

Kris
Kris

Reputation: 4823

I'm also wondering about this whole Akka and thread stuff for a while so I did some research and this is what I came up with. I hope it helps.

Play is using Akka for its thread management and concurrency. The advantage is that one doesn't have to care about the hassles of concurrency during your application programming any more.

Akka is using dispatchers for managing processor time of it's actors (actors are where the actual calculations happen in Akka).

Dispatchers are one of the most important parts of Akka.NET, as they control the throughput and time share for each of the actors, giving each one a fair share of resources.

Akka allows different dispatchers but the default one is 'fork-join-executor' and this is also the one Play is using by default.

In your configuration you set the minimum and maximum number of threads to 300. This way you fix the number of threads to 300 since you want your thread pool size quite large because you have many synchronous database calls. You have 300 threads independent of the number of your processors. If you buy a new server with more processors it's still 300.

Otherwise, if don't set the min and max number of threads, the dispatcher would do some calculation along the formula available processors * parallelism-factor. Of course you could also set this parallelism-factor to adjust to different number of processors of different servers. So if you put this parallelism-factor to 75 it would lead to max 300 threads on a server with 4 processors and max 600 on one with 8 processors.

In Akka's source code it's documented with:

The parallelism factor is used to determine thread pool size using the following formula: ceil(available processors * factor). Resulting size is then bounded by the parallelism-min and parallelism-max values.

If you want to read more about Akka and dispatchers I recommend the documentation to akka-concurrency-test which itself has a good list of sources.

Upvotes: 3

Related Questions