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-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org