End-to-end latency of a fault-tolerant CORBA infrastructure

Zhao, Wenbing; Moser, Louise E.; Melliar-Smith, P. M.

doi:10.1016/j.peva.2005.03.002

Cited by 6 publications

(6 citation statements)

References 22 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The latency probability functions for Totem were determined analytically by [19], analysis that was experimentally verified in a subsequent work [20]. Finally, the end-to-end latency of remote methods invoked in a replicated CORBA server built atop Totem was analyzed in [21]. Our findings are consistent with the analysis presented in these studies: Spread provides controlled latency, as a result of carefully designed flow control mechanisms.…”

Section: Related Worksupporting

confidence: 75%

“…When the response time has been of interest, its average over periods of system operation has been considered, rather than its stability and equality across requests. An exception is Totem, Spread's atomic broadcast protocol, that had its latency distribution studied in some works [19,20,21]. The latency probability functions for Totem were determined analytically by [19], analysis that was experimentally verified in a subsequent work [20].…”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Chasing the Tail of Atomic Broadcast Protocols

Cason

Marandi

Buzato

et al. 2015

2015 IEEE 34th Symposium on Reliable Distributed Systems (SRDS)

View full text Add to dashboard Cite

Many applications today rely on multiple services, whose results are combined to form the application's response. In such contexts, the most unreliable service and the slowest service determine the application's reliability and response time, respectively. State-machine replication and atomic broadcast are fundamental abstractions to build highly available services. In this paper, we consider the latency variability of atomic broadcast protocols. This is important because atomic broadcast has a direct impact on the response time of services. We study four high performance atomic broadcast protocols representative of different classes of protocol design and characterize their latency tail distribution under different workloads. Next, we assess how key design features of each protocol can possibly be related to the observed latency tail distributions. Our observations hint at request batching as a simple yet effective way to shorten the latency tails of some of the studied protocols; an improvement within the reach of application implementers. Indeed, our observation is not only verified experimentally, it allows us to assess which of the protocol's key design principles favor the construction of latency predictable protocols.

show abstract

Section: Related Worksupporting

confidence: 75%

Section: Related Workmentioning

confidence: 99%

Chasing the Tail of Atomic Broadcast Protocols

Cason

Marandi

Buzato

et al. 2015

2015 IEEE 34th Symposium on Reliable Distributed Systems (SRDS)

View full text Add to dashboard Cite

show abstract

“…However, the standard remains silent on how these parameters should be set or re-tuned over the application's lifetime [1]. Even for a static configuration with fixed values of these parameters, the endto-end latencies are hard to bound because they exhibit skewed and sometimes bimodal distributions [3]. For the CORBA Component Model, it has been noted that a small number of outliers (typically less than 1%) causes maximum latencies to be much larger than the average latencies [2].…”

Section: Problem Backgroundmentioning

confidence: 99%

“…However, recent studies have independently reported that the maximum end-to-end latencies of both CORBA and Fault Tolerant CORBA (FT-CORBA) middleware can be several orders of magnitude larger than the average latencies and might not follow a visible trend -even in the absence of faults [2,3]. This problem has been observed in many systems, especially when combining several third-party COTS components [4].…”

Section: Introductionmentioning

confidence: 99%

Got predictability?

Dumitraş

Narasimhan

2007

Proceedings of the 2007 ACM/IFIP/USENIX International Conference on Middleware Companion

View full text Add to dashboard Cite

Unpredictability in COTS-based systems often manifests as occasional instances of uncontrollably-high response times. A particular category of COTS systems, fault-tolerant (FT) middleware, is used in critical enterprise and embedded applications where predictability is of paramount importance. Our prior empirical study, which used a clientserver microbenchmark, suggested that hard bounds for the maximum latency are hard to establish a priori, but that the unpredictability may be confined to less than 1% of the requests. In this paper, we present empirical data, from 7 different three-tier, FT-middleware applications, that shows strong evidence supporting this "magical 1% " hypothesis. We conducted a controlled experiment with 7 teams of students from a graduate-level course at Carnegie Mellon University. Each team, starting from a common three-tier architecture, independently implemented and evaluated an original application using middleware (either CORBA or EJB) and a custom-implemented fault-tolerance mechanism (relying on either state-machine or primary-backup replication) for the middle-tier server. This experiment shows that unpredictability may not be avoidable, even in the absence of faults, and that, in some cases, the random latency outliers are larger than the time needed to recover from a fault. The data also reveals a statistically-significant result that, across all 7 applications, unpredictability is confined to the highest 1% of the recorded end-to-end latencies and is not correlated with the request rate, the size of messages exchanged or the number of clients. This suggests that strict predictability is hard to achieve in FT-middleware systems and that developers of critical FT applications should focus on guaranteeing bounds for statistical measures, such as the 99 th percentile of the latency.

show abstract

“…As the throughput increases, the overhead increases from about 50% to more than 100%. Detailed measurements the cost of the token-based fault tolerance infrastructure can be found in [20]. Figure 4 (b) shows the latency for the second activity, i.e., two-phase commit.…”

Section: Performance Measurementsmentioning

confidence: 99%

Unification of replication and transaction processing in three-tier architectures

Zhao

Moser

Melliar-Smith

Proceedings 22nd International Conference on Distributed Computing Systems

Self Cite

View full text Add to dashboard Cite

In this paper we describe a software infrastructure that unifies replication and transaction processing in three-tier architectures and, thus, provides high availability and fault tolerance for enterprise applications. The infrastructure is based on the Fault Tolerant CORBA and CORBA Object Transaction Service standards, and works with commercialoff-the-shelf application servers and database systems.The infrastructure replicates the application servers to protect the business logic processing. In addition, it replicates the transaction coordinator, which renders the twophase commit protocol non-blocking and, thus, avoids potentially long service disruptions caused by coordinator failure. The infrastructure handles the interactions between the application servers and the database servers through replicated gateways that prevent duplicate requests from reaching the database servers. The infrastructure implements client-side automatic failover mechanisms, which guarantees that clients know the outcome of the requests that they have made. The infrastructure starts the transactions at the application servers, and retries aborted transactions, caused by process or communication failures, automatically on the behalf of the clients.

show abstract

End-to-end latency of a fault-tolerant CORBA infrastructure

Cited by 6 publications

References 22 publications

Chasing the Tail of Atomic Broadcast Protocols

Chasing the Tail of Atomic Broadcast Protocols

Got predictability?

Unification of replication and transaction processing in three-tier architectures

Contact Info

Product

Resources

About