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

[Manik Surtani]

On 22 Jul 2009, at 11:22, Mircea Markus wrote:

> 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 ??? :)

Not at all!  :)  Ideally all deadlocks could be removed.  But until  
they are (or for the few that cannot feasibly be removed without a lot  
of reengineering), deadlock detection helps.  But if there is a system  
with a very high percentage of deadlocks due to colliding transactions  
(as in your test), then the solution is to reengineer the application.

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

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