[infinispan-dev] Let me understand DIST

[Bela Ban]

ok

On 3/15/12 3:45 PM, Pedro Ruivo wrote:
> Hi,
>
> Comment inline.
>
> Cheers,
> Pedro
>
> On 3/15/12 8:34 AM, Bela Ban wrote:
>>
>> On 3/12/12 7:13 PM, Pedro Ruivo wrote:
>>> On 3/10/12 5:07 PM, Bela Ban wrote:
>>>> If so, then I can assume that a transactional modification touching a
>>>> number of keys will almost always touch *all* nodes ? Example:
>>>> - We have 10 nodes
>>>> - numOwners = 2
>>>> - If we have a good consistent hash, I can assume that I have to modifiy
>>>> 5 different keys (10 / 2) on average in a TX to touch *all* nodes in the
>>>> cluster with the PREPARE/COMMIT phase, correct ?
>>>>
>>>> If my last statement is correct, is it safe to assume that with DIST and
>>>> transactional modifications, I will have a lot of TX contention /
>>>> collisions ?
>>> We have run experiments with ISPN 5.2 and TPC-C (1 warehouse, which
>>> gives a high probability of contention among transactions), and compared
>>> it with ISPN 5.0 (where locks were acquired on all replicas of a key,
>>> not only on the primary).
>>>
>>> The results running w/o write skew check and 10 nodes on our cluster
>>> (number of owners=2) follow:
>>>
>>>                     Tx/sec    Abort Rate
>>> 5.2            12         15
>>> 5.0            3           30
>>> 5.0-TOM   60         0
>>
>> Excellent ! It shows that 2PC has really improved between 5.0 and 5.2...
>>
>> Have you run TOM on Infinispan-5.2 / JGroups 3.1 yet ? It should
>> theoretically still be 60 TXs/sec. But even compared to 12, this is
>> still much better !
>>
>>
> I've not run it yet. I want to make the code stable (TOM with and
> without the write skew check) before starting the benchmark of the
> protocol. I'm still having some problems with the write skew check :P
>>>>      Also, if we touch almost all nodes, would it make sense to use SEQUENCER for
>>>> *all* updates ? Would this obviliate the need for TOM (total order for
>>>> partial replication) ?
>>> This could be done, you are right, it's what sometimes is called
>>> "non-genuine" partial replication. Our take on this is that this will
>>> work good on small scale clusters, not on large ones.
>>
>> I agree
>>
>>
>>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)