1 / 14

Performance Analysis of the novel Virtually Synchronous Group Communication Service

Performance Analysis of the novel Virtually Synchronous Group Communication Service. …. VS GCS. Group Communication -- Useful “Building Block”. Group Abstraction processes interact in a group dynamic: fail/join/partition/merge Group Multicast enforces certain ordering and reliability

nishan
Télécharger la présentation

Performance Analysis of the novel Virtually Synchronous Group Communication Service

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Performance Analysis of the novel Virtually Synchronous Group Communication Service … VS GCS

  2. Group Communication -- Useful “Building Block” • Group Abstraction • processes interact in a group • dynamic: fail/join/partition/merge • Group Multicast • enforces certain ordering and reliability • Group Membership • tells each process who it is connected to: current “view” • Virtual Synchrony • integrates Group Multicast and Group Membership • synchronizes message and view deliveries

  3. Example: Group Communication

  4. Virtual Synchrony • Synchronization of Messages and Views: • Before delivering new view v to its client, process has to synchronize with others • Powerful abstraction for replication • Semantics: VS [Birman, Joseph 87], EVS, SVS Processes that transition together through same views, deliver same sets of messages.

  5. Example: Virtual Synchrony VS algorithm executes: r learns it missed m and delivers m

  6. Performance Challenges in WANs • Clients care how fast the GCS delivers new views after a network event (NE) occurs • After NE: MBRSHP forms view, VS synchronizes NE View Delivered VS Algorithm View Formation • Existing systems (were designed for LANs): • Both MBRSHP and VS several rounds of msg exchange • Once begin, unable to respond to NEs -- “obsolete views” • They are inappropriate for WANs, which typically have • high and unpredictable message latency, • frequent connectivity changes

  7. Novel Algorithm for Virtual Synchrony[Keidar, Khazan 00] • Single message exchange among procs of new view • In parallel to MBRSHP forming the new view • No obsolete views -- reacts to membership changes NE View Delivered VS Algorithm View Formation • Scalable architecture: MBRSHP is decoupled from VS • Formal modeling: specs, algs, safety & liveness proofs • Can work with novel MBRSHP service[Keidar, et al 00] • View delivery in one message exchangein almost all cases

  8. Challenges of Formal Performance Analysis • The GCS system is a composition of building blocks • Multicast service, Membership service, VS end-points • Clients care about performance of the whole system • How fast after a network event new views are delivered • But our design focuses on the novel VS algorithm • Reduces the number of communication rounds to one, which are in parallel with MBRSHP forming new view • How can analyze improvement due to novel VS? • If MBRSHP and MCAST services are only specified • How to compare performance with existing GCSs? • If existing GCSs blend MBRSHP and VS together

  9. Performance Analysis: The Plan • Analyze the VS layer only • in terms of its inputs • and timing assumptions • State reasonable performanceproperties of MBRSHP and MCAST • Compose  with  to yield conditional Corollaries • “Provided  holds, the whole system performs like this…” • Next step: Compare  with existing VS GCSs

  10.  Analysis of the VS layer • Assume component C stabilizes after some time on: • MBRSHP delivers same views to VS end-points of C Let Tmax[MBRSHP.start] and Tmax[MBRSHP.view] be last events • MCAST provides reliable and timely communication Let  be message latency • Liveness proof establishes that VS delivers views • Upper-bound the times when VS outputs views • In terms of the times when MBRSHP outputs occur • Conditional on timing assumptions (local speed: ) Tmax[MBRSHP.start] +  + x +  Tmax[MBRSHP.view] Tmax[VS.view]  max

  11. Illustration One msg latency  + x Tmax[VS.view] view VS Algorithm NE last start start view first last last MBRSHP algorithm Tmax[MBRSHP.start] Tmax[MBRSHP.view]

  12.  Bounds on MBRSHP NE Reasonable bounds on the times of MBRSHP events Tmin[MBRSHP.start] Tmax[MBRSHP.start] Tmax[MBRSHP.view] start start view One all-to-all msg latency ~One msg latency  ~One msg latency  first last last MBRSHP algorithm These bounds correspond to Fast-Path of [Keidar, et al 00] observed empirically in almost all cases

  13.  Compose MBRSHP and VS bounds One msg latency  + x Bounds on the whole system, conditional on MBRSHP view VS Algorithm NE Tmax[VS.view] Tmin[MBRSHP.start] Tmax[MBRSHP.start] Tmax[MBRSHP.view] last start start view One all-to-all msg latency ~One msg latency  ~One msg latency  first last last MBRSHP algorithm

  14.  Next Step: Comparison with existing GCSs • Existing VS algorithms all use similar ideas • Pre-agree on common identifiers. Deliver obsolete views • Formulate a high-level description of existing algs • Requires looking at inherent costs (e.g., all-to-all latency) • Analyze under the same scenarios and conditions • Express performance advantages due to: • Faster VS algorithm that doesn’t pre-agree on common ids • Not wasting time on obsolete views

More Related