Questions about thread pool for blocking IO

(Tanin Na Nakorn) #1

Hi Players,

I’ve been reading a lot about how to tune Play’s thread pool properly, and I want to make sure I understand this topic correctly. I have 2 questions:

  1. For blocking IO, we should provide a separate thread pool that has high number of threads. Is that accurate?
  2. Does Slick (which uses JDBC) uses blocking IOs?

Thank you,

(Greg Methvin) #2
  1. Yes, you generally want to use a separate thread pool for blocking I/O. The right number of threads depends a lot on your work load. There are some rules of thumb, like for JDBC you’d typically use the same or slightly more threads than the size of your connection pool.
  2. Yes, Slick uses blocking I/O, but Slick 3 wraps the blocking I/O in an asynchronous API and takes care of (1) for you automatically. It does that by creating a separate thread pool for database I/O operations and implementing a queue for pending queries. In Slick 2 the API actually blocks.

(Tanin Na Nakorn) #3

Thank you, Greg!

(Tanin Na Nakorn) #4

Actually, I have more questions.

Would it make sense to always set parallelism-min to 1? I don’t see any reason to set it to, say, 8 when I have 8 cores because, with parallelism-factor = 1.0, we almost always use 8 threads anyway.

I think the question is: in what situations do I want to set parallelism-min to anything else other than 1?

(Tanin Na Nakorn) #5

I think I can answer my own question here.

The reason to set parallelism-min is to avoid a deadlock. If we set it to 1, and, for some reason, our cpu has 1 core, and some part of our code is blocking, then we might encounter a deadlock. So, having a guarantee of parallelism is better.