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

Manik Surtani manik at jboss.org
Wed Jul 22 05:59:03 EDT 2009


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

--
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