Hi Muthu
Great to know you are evaluating Shoal.
It would help us a lot if you can share more details about the
characteristics of the deployment you have in mind.
That would help us give you more specific answers or take more RFEs for
improvements.
Cheers
Shreedhar
Mohamed Abdelaziz wrote:
> The JXTA survey focuses on discovery and scalability of such in a
> large super-node. It relies on discovery for grid formation, a
> mechanism only suited for bootstrapping, and intentionally designed
> not to be exhaustive, which leads to the long discovery times. Shoal
> relies on alternate mechanisms better suited for the task. (also,
> jxta startup completes in sub-second)
>
> As for the second link you point, such benchmarks were performed prior
> to any of the performance and optimization that have taken place over
> the past 3 years. I would expect that if such benchmark, if rerun
> again, would reveal little to no depredation in throughput, and
> drastic improvement to latency.
>
>
> As for sizing, Shoal does not require any infrastructure (super-nodes)
> in single sub-net, and requires a super node to facilitate cross
> network formation. In previous benchmarks, I was able to create a
> shoal cluster close to 128 instances.
>
> As for capacity planning when deploying geographically distributed
> clusters, it is key to designate the correct number of super node in
> support on inner-cluster communication. This figure depends on well
> equipped such super nodes and the number client nodes they can support.
> A simple to think of this, is to correlate super-nodes to switches in
> a IGMP environment, as the most significant function it provides to
> shoal is message propagation within a cluster in very similar fashion
> to how IGMP functions. Obviously designating more than one super
> nodes distributes such load within a cluster.
>
>
> Mohamed
>
>
> Muthukumaran Kothandaraman wrote:
>>
>> Hi,
>>
>> I stumbled across some of the JXTA scalability studies and following
>> caught me
>> http://www.disi.unige.it/person/FerranteM/papers/JXTA-survey.pdf
>> and
>> http://hal.inria.fr/docs/00/12/03/18/PDF/RR-6064.pdf
>> both seems to indicate that discovery-duration continues to increase
>> as peer-view size increases. This must in someway be influencing the
>> sizing of a Shoal-based cluster so that discovery-duration does not
>> adversely affect the application expectations (eg. if an application
>> with high transactional-rates is composed of 50 processes - 25
>> distinct application processes in ACTIVE mode and 25 replicated
>> processes on STANDBY mode, on same GMS-group, significant raise in
>> peer-discovery times would affect any fault-tolerance/failover
>> handling).
>>
>> Is this the case and if so, what could be guidelines for sizing the
>> cluster beyond which it starts following "law of diminishing returns"?
>>
>> Regards
>>
>> Muthukumaran (Muthu)
>> Systems Engineer
>> IBM India Private Limited
>> Bangalore
>>
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net
> For additional commands, e-mail: users-help_at_shoal.dev.java.net
>