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

[Mircea Markus]

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.
> -- 
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>