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.

SOLUTION

Am P

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

ASKER CERTIFIED SOLUTION

dpearson

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Jay Roy

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 ?

Jay Roy

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

We'll have to monitor all the timings.

For opensource:
http://java-source.net/open-source/profilers

For commercial:
http://www.appperfect.com/support/tutorials/java-server-profiling.html

Jay Roy

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

Jay Roy

ASKER

Thanks Doug, that helps.
Have you tried using any profiler to compute ratio of wait time to compute time?

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

Jay Roy

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

Jay Roy

ASKER

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