Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.220.50 as permitted sender)
Message-ID: <541F0DC0.9080501@gmail.com>
Date: Sun, 21 Sep 2014 10:41:20 -0700
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [Pool] Performance Tests for Pool-277
References: <20140920075013.0000070d.ecki@zusammenkunft.net>
 <541F0B49.8060905@gmail.com>
In-Reply-To: <541F0B49.8060905@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

On 9/21/14 10:30 AM, Phil Steitz wrote:
> On 9/19/14 10:50 PM, Bernd Eckenfels wrote:
>> Hello,
>>
>> re https://issues.apache.org/jira/browse/POOL-277
>>
>> I would like to commit VFS-277 fix (nonlockstats2.patch). However before
>> I do that, I would like to test if it is really a perfomrmance
>> improvement. Lucas confirms it helps in his scenario.
>>
>> I have run the included PerformanceTest, but the results have been
>> indifferent. Are those tests reliable? Can somebody with some
>> experience re-run them on their machine? (I somewhat feel the need to
>> provide a JMH test :) 
> I have started running some performance tests using commons
> performance (sandbox).  I mostly use [performance] to get races or
> other bugs to happen, but it does give an idea of gross performance
> differences.  So far, I have not been able to detect any performance
> benefit from the patch.  That does not mean that there is no
> benefit, especially since I have only 4 cores on the test box.  I
> have some longer-running tests running now and will report back if I
> find anything.
>
> Even if the patch does improve performance, I am -0 on applying as
> is, as the implementation appears to change the meaning of
> getMaxBorrowWaitTimeMillis.  The current implementation returns the
> max since the pool was created, not a rolling window of recent
> values, as the patch appears to do (unless I am missing something). 
> The unit tests for reported JMX stats are pretty weak, so we need to
> be careful relying on them to confirm correctness.

Looking more carefully at the patch, I think what I stated above is
incorrect - i.e., the global max should be returned, so that is not
a blocker here.  Sorry I misunderstood the code.  Now we need to
confirm that there is in fact a performance benefit.  Also, we
should look at the impact on the getters performance - I suspect
they will be a little slower.

Phil
>
> Phil
>> My proposed patch:
>> https://issues.apache.org/jira/secure/attachment/12670185/nolockstats2.patch
>>
>> Gruss
>> Bernd
>>
>> ---------------------------------------------------------------------
>> 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