Great stuff Bela! Btw, is xsite replication bidirectional? LON has SFO as backup, and SFO also has LON as backup.
On Fri, Dec 14, 2012 at 8:01 PM, Sanne Grinovero <[email protected]>wrote: > That was very very nice to see. > > Assuming you also asked for feedback to improve this as a talk: > > 1# you stress several times that reads are going to be local, so very > fast. I think you meant "local to the site" ? as some ~33% of entries > will need to be fetched from peers on the same site. > > 2# you aren't actually running this on multiple sites are you? When > pointing out the different IP addresses you say something about > needing them to be different, but I didn't understand if you needed > them different because they are in different places, or to separate > otherwise local machines to have them appear as in different places. > > 3# Since get operations are always local (site), they are as you say > not meaningful for the benchmark; now since put operations are also > not meaningful as it's async .. what is the benchmark measuring? > > 4# There seems to be some degree of redundancy when explaining > LON/SFO/NYC setting as the local site vs the backup sites. Wouldn't it > make more sense to be able to configure all backup sites the same and > have it automatically ignore the "self" element as a backup site? So > your script would only need to specify what the local site is. If that > makes any sense it would even be nice to extend this to the IP > addresses being defined in the zones area, so that they are applied > both to the JGroups configuration for the local cluster and to the > bridge configuration. > > 5# I was initially surprised to see x-site configuration as part of a > cache configuration; I understand the reasons for options like > "strategy" which one might want to specify differently on each cache, > but what about "take offline" ? that sounds more something which > should be globally managed at the channel level - not sure if in > JGroups directly but if it's to be handled in Infinispan I would > expect to have all caches use the same policy, consistent with FD. > Also it doesn't looks like you have much of a choice in to which sites > you want to replicate, as relay is setup at the jgroups level so > affecting all caches: is relay going to be ignored by caches having no > x-site enabled? And is it going to be relayed only to one site if the > Infinispan configuration lists a single site? > Not sure if this makes any sense, I just found it contrasting with my > naive expectations of how such a configuration would look like. > > thanks a lot, I hope this is proof enough that your video was pretty > catchy :) > Cheers, > Sanne > > On 14 December 2012 11:47, Radoslav Husar <[email protected]> wrote: > > Thanks Bela, I enjoyed the demo! > > > > I suggest adding some sort of visualization (maybe just a few diagrams > > within the demo) of what is actually happening with the data would help > > understanding for users who are just starting with xsite. > > > > Rado > > > > On 14/12/12 12:09, Bela Ban wrote: > >> FYI, > >> > >> I've uploaded a 10-minute video [1] to YouTube showing how I setup and > >> run a perf test for Infinispan xsite replication [2]. The test > >> (including all configuration) is available at [3]. This was run with a > >> snapshot of Infinispan (roughly 5.2.0.Beta6) and JGroups 3.3.0.Alpha1. > >> Enjoy ! > >> > >> [1] http://www.youtube.com/watch?v=owOs430vLZo > >> [2] https://docs.jboss.org/author/display/ISPN/Cross+site+replication > >> [3] https://github.com/belaban/IspnPerfTest > >> > > _______________________________________________ > > infinispan-dev mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
