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

Manik Surtani wrote: > > 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. :-) Are you just telling me that this functionality is useless ??? :)

Yes, that's what one needs (and should do), where possible. Even so, it was a bit difficult (not anymore) to determine weather there are deadlocks in the system, or just regular timeouts. I've also exposed the deadlock detection info through JMX - I'll make sure this appears as a not in the blog I'll write. > > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > >