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

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.