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
>
>
>
>
>