[infinispan-dev] DeadlockDetection (DLD) - benchmarks and status
Manik Surtani
manik at jboss.org
Wed Jul 22 06:25:55 EDT 2009
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
More information about the infinispan-dev
mailing list