Re: [infinispan-dev] DeadlockDetection (DLD) - benchmarks and status

On 22 Jul 2009, at 11:06, Mircea Markus wrote: > Manik Surtani wrote: >> >> On 22 Jul 2009, at 10:42, Mircea Markus wrote: >> >>> Manik Surtani wrote: >>>> <SNIP /> >>>> >>>>>> So you do force a lot of deadlocks as a result. And the time >>>>>> taken with the non-DLD case would depend on the TM's transaction >>>>>> timeout configuration which again would vary. >>>>> The Dummy TM does not force rollback based on tx timeout, indeed. >>>>> Another important factor it depends on is the >>>>> lockAcquisitionTimeout. Still, it's up to the user to benchmark >>>>> against its very specific scenario. >>>> >>>> Sorry yes, I meant lockAcquisitionTimeout in my prev. comment. >>> In this case lowering lock acquisition timeout would result in >>> rollbacks of non-deadlocked txs as well, so not sure the overall >>> outcome is better. >> >> My point is that any gain (measured as a percentage or a factor) is >> directly related to the lock acquisition timeout. Which is, in >> turn, hugely application-specific. :) >> >>>> >>>>>> So as a result I'd be careful about quoting performance increase >>>>>> factors in a public blog (although you should definitely blog >>>>>> about this as a feature and how it *could* speed up transactions >>>>>> that would otherwise timeout). >>>>> Point taken. Are you also thinking not to bring up the diagrams? >>>>> After all, they the numbers there are real: so by mentioning the >>>>> context (intended high collision) and no tx timeout, they are >>>>> relevant. >>>> >>>> Well, the numbers are only real given the rate of colliding >>>> transactions (versus non-colliding ones) and the lock acquisition >>>> timeout that you used. Which is artificial, or at best specific >>>> to a certain use case. But either way, not generic enough to >>>> publish since it would lead people to believe that they can expect >>>> a 500% performance boost when using deadlock detection, and get >>>> really pissed off when they *only* get a 25% performance boost >>>> since most of their transactions don't collide anyway. :-) >>> What about a pool of 50 objects? Or 100? >> >> Again, this is entirely artificial. How many of these should >> collide? Is it realistic? :-) > I think these numbers give a better understanding to the user than > saying "DLD might/will have a significant performance increase in an > environment where you have a significant collision". Also the test > environment would be clearly described, so no user would expect an > 500% increase out of the blue. I think the real solution in a system that has a lot of deadlocking transactions is to try and redesign the app so that these deadlocking transactions do not occur. :-)

-- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org