commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [Pool] Performance Tests for Pool-277
Date Sun, 21 Sep 2014 17:41:20 GMT
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


Mime
View raw message