Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nx02.iad01.newshosting.com!newshosting.com!216.196.98.146.MISMATCH!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 30 Nov 2011 05:11:25 -0600
Date: Wed, 30 Nov 2011 03:11:22 -0800
From: Patricia Shanahan <pats@acm.org>
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
Newsgroups: comp.lang.java.programmer
Subject: Re: Thread question
References: <i9tbd7ppgalucct4i2t2agj9hldjumnmk4@4ax.com> <081cd7paqgsa8bbg5gjh8v1kinfp7asgt0@4ax.com>
In-Reply-To: <081cd7paqgsa8bbg5gjh8v1kinfp7asgt0@4ax.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <YbKdnc-ylpHAkkvTnZ2dnUVZ_vudnZ2d@earthlink.com>
Lines: 40
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 70.230.194.31
X-Trace: sv3-yppgudrFxWFT2hF00EZVdEtwCO1OgVNJggp0OY3SCRTOFHfBihUbxqVPR8xfCHMofjDx3EcVOAOD6sQ!l95ScJKwARoxLHNrnHJUt44PYJySdXQQGEtCOgnLzczgmvJmkio4FQuFzA+seqm4EEF9di4zpjkP!z9oqABOkjda8HvBChsx+NXi0YfK3dahA0hzRgIiiks58AA==
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 2931
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:10353

On 11/30/2011 2:32 AM, Roedy Green wrote:
...
> I'll be curious to find out the optimal number of threads.  I don't
> like to pester the book stores. I can debug this with 2 threads
> without doing too much pestering, but repeated runs to binary search
> the optimum number of threads...  maybe I should use the fancy
> features to dynamically adjust it via a feedback mechanism.
>

Here's a basic approach to picking a thread count:

1. Measure a single thread and a small number of threads, and estimate
the usage for each critical resource as a function of the number of
threads.

The critical resources will be things like CPU utilization, memory
footprint, and average number of outstanding requests. For most
resources, N threads will have N times the utilization of a single
thread. Memory footprint will probably show an overhead for shared code
plus a component that scales with the number of threads.

2. Decide how much of each resource you want to permit the job to use.
This may change with e.g. the hardware configuration on which it is
running. It is rarely a good idea to allow one job to use the whole of
anything.

3. For each resource, calculate the maximum number of threads that will
not overload the resource.

4. Pick the smallest result from step 3. That is the largest number of
threads that will not overload any resource.

For example, suppose you are willing to have an average of 20 requests
outstanding, and each thread averages one request outstanding. Then that
resource sets a limit of 20 threads.

This approach needs only a couple of measurement runs and some decisions
about the total resource levels you want to dedicate to this job.

Patricia