Play 2.3 is this the way threads work or is my assumption wrong

25 views
Skip to first unread message

Ignacio Perez

unread,
Oct 2, 2015, 1:02:52 PM10/2/15
to play-framework
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.

Will Sargent

unread,
Oct 2, 2015, 2:10:34 PM10/2/15
to play-fr...@googlegroups.com
That's 300 threads available for servicing HTTP requests.   If you call out to a database in an HTTP request, then that thread is still blocked and that page will not be rendered.  That's bad, because you want your thread pool sized appropriately to your task.

Think of a thread pool as gears.  If you're only doing one thing, then you can use a small gear and move around very quickly -- for example, for HTTP requests that don't block, you want to have roughly the same number of threads as you have cores.  8 core CPU means 8 threads.

When you talk to a database, that's a blocking API, using IO and Network to talk to something very slow.  So you need a larger gear there, because it will take much longer for a response to get back to you.  You want to keep the CPU busy enough that there's always some database response coming back from some where, so you need more threads to cover the lag.  So you create a larger thread pool and assign it to managing the database requests.

Will.

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/ddfa17c2-66c1-4b01-a5ab-5cfccf0baa7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages