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

[Mircea Markus]

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