commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
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
>> 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
>> My proposed patch:
>> Gruss
>> Bernd
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message