Avatar of royjayd
royjayd
 asked on

Number of threads in ExecutorService

hi experts

According to brian goetz threadcount in executor service is

BigDecimal optimalthreadcount = numberOfCPU.multiply(targetUtilization).multiply(new BigDecimal(1).add(waitTime.divide(computeTime, RoundingMode.HALF_UP)));

We are using executor service in our project and want to determine how many threads we need to assign to it, we are trying to analzye the above formulae.

Can anyone explain how to calculate :
targetUtilization
waitTime
computeTime

any help would be greatly apprecaited
thanks.
Java

Avatar of undefined
Last Comment
royjayd

8/22/2022 - Mon
SOLUTION
Am P

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question
ASKER CERTIFIED SOLUTION
dpearson

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question
royjayd

ASKER
thanks, from one of your links:

>> Using profiling, you can estimate the ratio of waiting time (WT) to service time (ST) for a typical request.

do you know which kind of  profiler does that ?
royjayd

ASKER
from the links i read, it seems there are two options

1. n+1 threads for cpu intensive task and

2. number of processors* 1+ wait time/ compute time   for IO task
(http://www.ibm.com/developerworks/library/j-jtp0730/index.html)

however with java 7.0 releasing asynchronous NIO api threads shoud not block as much as it used to since asynchronous thread will be running in parallel to the main thread (if i am not wrong). i wonder how that would change the formulae if at all.

thanks.
Am P

Experts Exchange is like having an extremely knowledgeable team sitting and waiting for your call. Couldn't do my job half as well as I do without it!
James Murphy
royjayd

ASKER
well thats too generic, which profiler does that ? for example can i find out ratio of
wait time/compute time using Yourkit java profier ?
dpearson

The whole idea with NIO was to avoid blocking anyway (compared to not using NIO).

I think the new Java 7 APIs really just improve the visibility into how those tasks are operating (since you can get Futures and similar handles to the async executing tasks).  So you'll have better control with Java 7 but I don't think really better throughput.

So I don't think this really changes the formulae.

Doug
royjayd

ASKER
Thanks Doug, that helps.
Have you tried using any profiler to compute ratio of wait time to compute time?
Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.
dpearson


Have you tried using any profiler to compute ratio of wait time to compute time?

I've never tried that.  I think the simpler approach is to test a higher level property (e.g. requests per second) and tune the thread count while monitoring that value.  E.g. Set it to x, 2x, 3x and measure the requests per second of the entire system to see which produces the "best" performance (however you define best - highest throughput usually, but maybe not always).

That's the real goal.  Tuning the efficiency of a single executor based on estimating the wait to compute time seems a bit low level to me.  Just my 2 cents.

Doug
royjayd

ASKER
Yes, it is pretty low level. It would have been nice if goetz could use a sample scenario
to calculate threadcount in his book.
dpearson

True - although I feel like Goetz's books on threading accounted for about 80% of my understanding of concurrency behavior, which I now work on every day - so I'll forgive him this omission :)

Doug
This is the best money I have ever spent. I cannot not tell you how many times these folks have saved my bacon. I learn so much from the contributors.
rwheeler23
royjayd

ASKER
Lol, an amazing book. I have cleared some tough java interviews after reading that book.