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

[Manik Surtani]

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