Yes, with 5.2.3 it makes sense - in replication mode there were less
messages used for the write but key may have different value on
different nodes after concurrent modification. In order to evade this,
you can setup 4-node distributed cluster with numOwners=4.
All the performance optimizations depend on how consistent the storage
has to be. Do you write to the same keys in one moment from multiple
locations? Would you be OK with a bit out-of-date reads? Is it a problem
if you read different values for the key on different nodes? Is it a
problem to a write getting lost once a while?
With strong consistency requirements, you can't get top performance, but
maybe you don't really need it - or you need it just for some data in
your app which can be positioned into cache with different configuration.
There is a nice table [1] for asynchronous options guarantees.
And by the way - "my application involves both reads and writes heavily"
does not say anything - the factor is the ratio (percentage) of reads to
writes.
Radim
[1]
Hi,
I am using infinispan 5.2.3.
My configuration is non-transactional, synchronous.
With this configuration, is my replication supposed to perform better than
distribution, for both reads and writes?
My Cluster Size requirement is 4 nodes.
And my application involves both reads and writes heavily.
For better performance, are there any suggestions on the clustering
modes/configurations?
All my tests show, replication having better performance than distribution for reads
as well as writes, with 4 nodes.
Thanks,
Faseela
-----Original Message-----
From: infinispan-dev-bounces(a)lists.jboss.org
[mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Radim Vansa
Sent: Monday, August 12, 2013 6:13 PM
To: infinispan-dev(a)lists.jboss.org
Subject: Re: [infinispan-dev] Recommended Cluster Size for Replication Mode
Hi,
which version exactly do you use, 5.2.x, 5.3.x or 6.0.x? In 5.2 the replication mode was
implemented separately from distribution mode and depending on your configuration (is it
non-transactional synchronous?) the message control flow could differ. Since 5.3
replication mode is implemented in the same manner and the results should be more
comparable.
I may be wrong here, but in 5.2.x concurrent writes to single key in non-transactional
mode could result in entries being out of sync on some nodes (the writes could arrive at
two nodes in different order). I think this cannot happen in >= 5.3 anymore.
Radim
On 08/12/2013 09:04 AM, Faseela K wrote:
> Hi,
>
> With a 3 node cluster, even for "WRITES" my replication performance is
better than distribution.
> That's why I came across this doubt.
> Could some body please clarify, why the behaviour is like this?
>
> Thanks,
> Faseela
>
> -----Original Message-----
> From: infinispan-dev-bounces(a)lists.jboss.org
> [mailto:infinispan-dev-bounces@lists.jboss.org] On Behalf Of Mircea
> Markus
> Sent: Friday, August 09, 2013 7:14 PM
> To: infinispan -Dev List
> Subject: Re: [infinispan-dev] Recommended Cluster Size for Replication
> Mode
>
> On 6 Aug 2013, at 15:19, Faseela K <faseela.k(a)ericsson.com> wrote:
>
>> What is the recommended cluster size for Replication Mode?
>> Given 3 nodes, My replication configuration performs better than my
distributed configuration.
>> Just wanted to know, at what cluster size, distribution will perform better
than replication.
> There's no straight answer, it depends on the read/write ratio and the amount of
data you store.
> Replication will always perform better for reads as it won't involve a remote
call to get the data.
> If you're mostly doing reads and your memory allows (replication is more memory
consuming) then you should use replication.
> If the amount of data increases or you're doing more writes, distribution is the
way to go.
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (
www.infinispan.org)
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev