this was done with 2 node MB cluster. We need to test and decide with larger cluster sizes.
On Thu, Apr 30, 2015 at 5:59 PM, Afkham Azeez <[email protected]> wrote: > Was this test done with a single MB instance or while having more than 1 > MB instance in the same cluster? > > On Thu, Apr 30, 2015 at 5:56 PM, Ramith Jayasinghe <[email protected]> > wrote: > >> HI Shanker, >> We keep lots of state in Hazel-cast IMaps for MB. >> What we want to achieve by this experiment is to figure out weather we >> can reduce the inconsistencies that could happen during failover scenarios >> (we are yet to do a failover test round with this, will keep everyone >> updated with the progress). >> >> May be we can make this the default way of keeping slot based >> information if things work better compared hazelcast approach ( - again we >> are going to determine by testing the performance and failover scenarios). >> >> However, I prefer to keep both options available for the users and then >> eventually deprecate one approach over time. >> >> >> On Thu, Apr 30, 2015 at 5:28 PM, Selvaratnam Uthaiyashankar < >> [email protected]> wrote: >> >>> >>> >>> On Thu, Apr 30, 2015 at 5:00 PM, Anuja Herath <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> Is it single node MB? >>>> >>>> No, It is a cluster. I used two MB nodes for testing. Publisher in one >>>> node and Subscriber in another node. >>>> >>>> Database is in the same machine? >>>> >>>> For MS SQL, I used a separate machine with database server. >>>> For MySQL, I used database in the same machine. >>>> >>>> Any reason why we used MSSQL? >>>> >>>> MB performs faster in MS SQL, So initially, we wanted to test new >>>> implementation in that best case. >>>> We are planning to continue testing with other databases as well. >>>> >>>> Result looks there are not much difference between the two. So, what is >>>> the conclusion? >>>> >>>> MB is heavily depend on Hazelcast and use several hazelcast maps. And >>>> also we faced several problems related to that. >>>> This implementation was done as an experiment to release that heavy >>>> dependency on Hazelcast. >>>> We did not expect to increase performance with this implementation. But >>>> at the same time, we did not want to decrease performance with a new >>>> implementation. >>>> So with these preliminary test results, we concluded that there is no >>>> much different in performance between using RDBMS and Hazelcast for storing >>>> slot information. >>>> >>>> If the new implementation works with further testing, we will add an >>>> option to select either RDBMS or Hazelcast for storing slot information. >>>> >>> >>> >>> So, this is going to be one more configuration? How the users will know >>> which one is good for them? >>> >>> >>> >>>> >>>> Thanks, >>>> Anuja >>>> >>>> On Thu, Apr 30, 2015 at 4:29 PM, Selvaratnam Uthaiyashankar < >>>> [email protected]> wrote: >>>> >>>>> Is it single node MB? >>>>> Database is in the same machine? >>>>> Any reason why we used MSSQL? >>>>> Result looks there are not much difference between the two. So, what >>>>> is the conclusion? >>>>> >>>>> On Thu, Apr 30, 2015 at 12:12 PM, Anuja Herath <[email protected]> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I have implemented storing slot information using RDBMS. Previously >>>>>> MB used Hazelcast for storing these slot information. I have attached >>>>>> performance comparison related to above implementation. >>>>>> >>>>>> [1] Performance Results - >>>>>> https://docs.google.com/a/wso2.com/spreadsheets/d/1O9Mr-TiZaIyOBox4KhxQkcy_puG_i9JXe4xbPY3QPg4/edit?usp=sharing >>>>>> >>>>>> [2] Redmine Project - https://redmine.wso2.com/issues/3801 >>>>>> >>>>>> Thanks, >>>>>> Anuja >>>>>> >>>>>> -- >>>>>> Anuja Herath >>>>>> *Software Engineer* >>>>>> *WSO2, Inc.* >>>>>> Mobile : +94 (0)71 429 8861 >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> S.Uthaiyashankar >>>>> VP Engineering >>>>> WSO2 Inc. >>>>> http://wso2.com/ - "lean . enterprise . middleware" >>>>> >>>>> Phone: +94 714897591 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Anuja Herath >>>> *Software Engineer* >>>> *WSO2, Inc.* >>>> Mobile : +94 (0)71 429 8861 >>>> >>> >>> >>> >>> -- >>> S.Uthaiyashankar >>> VP Engineering >>> WSO2 Inc. >>> http://wso2.com/ - "lean . enterprise . middleware" >>> >>> Phone: +94 714897591 >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Ramith Jayasinghe >> Technical Lead >> WSO2 Inc., http://wso2.com >> lean.enterprise.middleware >> >> E: [email protected] >> P: +94 777542851 >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **[email protected]* <[email protected]> > * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * > *http://blog.afkham.org* <http://blog.afkham.org> > *twitter: **http://twitter.com/afkham_azeez* > <http://twitter.com/afkham_azeez> > *linked-in: **http://lk.linkedin.com/in/afkhamazeez > <http://lk.linkedin.com/in/afkhamazeez>* > > *Lean . Enterprise . Middleware* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Ramith Jayasinghe Technical Lead WSO2 Inc., http://wso2.com lean.enterprise.middleware E: [email protected] P: +94 777542851
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
