Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Date: Wed, 24 Sep 2014 01:51:20 +0200
From: Bernd Eckenfels <ecki@zusammenkunft.net>
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [Pool] Performance Tests for Pool-277
Message-ID: <20140924015120.00000402.ecki@zusammenkunft.net>
In-Reply-To: <5421B7DE.9070503@apache.org>
References: <20140920075013.0000070d.ecki@zusammenkunft.net>
	<541F0B49.8060905@gmail.com>
	<20140922015129.00004e66.ecki@zusammenkunft.net>
	<541F8986.3060202@gmail.com>
	<5421A6FB.9020102@gmail.com>
	<5421B7DE.9070503@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello Mark,

I did some micro benchmarks on the max-only thing. And they somewhat
look like I have expected on my 4core/8threads:

1 thread
Benchmark                               Mode  Samples         Score  Score error  Units
n.e.j.t.MyBenchmark.atomicMax          thrpt        5  71754699,465  4916943,615  ops/s
n.e.j.t.MyBenchmark.synchronizedMax    thrpt        5  31398785,726  1071751,697  ops/s

2 threads 
Benchmark                               Mode  Samples          Score  Score error  Units
n.e.j.t.MyBenchmark.atomicMax          thrpt        5  111773939,071  6478325,697  ops/s
n.e.j.t.MyBenchmark.synchronizedMax    thrpt        5    8197066,038   457199,732  ops/s

4 threads
Benchmark                               Mode  Samples          Score   Score error  Units
n.e.j.t.MyBenchmark.atomicMax          thrpt        5  190326272,383  11287614,702  ops/s
n.e.j.t.MyBenchmark.synchronizedMax    thrpt        5    5227629,001     35488,823  ops/s

6 threads
Benchmark                               Mode  Samples          Score   Score error  Units
n.e.j.t.MyBenchmark.atomicMax          thrpt        5  257831969,334  21506920,317  ops/s
n.e.j.t.MyBenchmark.synchronizedMax    thrpt        5    5437590,131    651603,805  ops/s

8 threads
Benchmark                               Mode  Samples          Score  Score error  Units
n.e.j.t.MyBenchmark.atomicMax          thrpt        5  308313078,989  7365995,913  ops/s
n.e.j.t.MyBenchmark.synchronizedMax    thrpt        5    4808905,027   657214,727  ops/s

16 threads
Benchmark                               Mode  Samples          Score   Score error  Units
n.e.j.t.MyBenchmark.atomicMax          thrpt        5  295064556,539  28027347,836  ops/s
n.e.j.t.MyBenchmark.synchronizedMax    thrpt        5    4974286,841     79612,105  ops/s


I would say one sees that both get slower when the active conurrency gets higher, but the atomic version is always faster. When there are more threads than cores it even gets a bit better.

So I would say it is safe to only replace the synchronized max version with the atomic one. The further changes like moving it to the stats store and cleaning up the mean calculation and the synchronized method can be left for later:

I would actually like to introduce a StatsStore interface where the user can register their own implementaions. They would have to provide add() and getMean() and getMax() but they can query all they want from their smart implementation (including percentils and stuff).

Until then, I attached a more minimal patch for the atomicMax of the borrow (only).

Gruss
Bernd

PS: code is here: https://gist.github.com/ecki/8350a276caa444a62dce


Am Tue, 23 Sep 2014 19:11:42 +0100
schrieb Mark Thomas <markt@apache.org>:

> On 23/09/2014 17:59, Phil Steitz wrote:
> > On 9/21/14 7:29 PM, Phil Steitz wrote:
> 
> <snip/>
> 
> >> I was not able to demonstrate any consistent performance difference
> >> in my tests.  The code in trunk was a tiny bit faster on average
> >> but some runs of the patched code were faster than some runs of the
> >> unpatched code.  It might be worth just changing the max to be
> >> "lock free" and seeing if that change by itself makes any
> >> difference. 
> > 
> > I did that and still could not demonstrate any improvement.  The
> > report in the ticket does show monitor contention, though, so I am
> > ambivalent on this one.  What do others think?
> 
> Typo: s/Mast/Must/
> 
> I have often found that for large numbers of cheap operations that
> monitoring tools are far more overhead than the thing they are trying
> to measure. I recently spent some time tuning a new Cookie parser for
> Tomcat and the profiler results were useless at identifying the real
> bottlenecks. I wonder if that is happening here.
> 
> I have no objection to the patch if the performance is about the same.
> Adding max to the StatsStore is likely to be useful elsewhere.
> 
> Mark
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org