1 / 27

Tolerating Latency in Replicated State Machines through Client Speculation

Tolerating Latency in Replicated State Machines through Client Speculation. April 22, 2009 Benjamin Wester 1 , James Cowling 2 , Edmund B. Nightingale 3 , Peter M. Chen 1 , Jason Flinn 1 , Barbara Liskov 2 University of Michigan 1 , MIT CSAIL 2 , Microsoft Research 3.

afya
Download Presentation

Tolerating Latency in Replicated State Machines through Client Speculation

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. Tolerating Latency in Replicated State Machines through Client Speculation April 22, 2009 Benjamin Wester1, James Cowling2, Edmund B. Nightingale3, Peter M. Chen1, Jason Flinn1, Barbara Liskov2 University of Michigan1, MIT CSAIL2, Microsoft Research3

  2. Simple Service Configuration 1 x=0 x=1 ++x Benjamin Wester University of Michigan CSE

  3. Replicated State Machines (RSM) • Agree on request • All non-faulty replies are identical 2 x=1 x=2 ++x 2 x=1 x=2 ++x x=1 x=2 2 ++x x=1 x=2 2 ++x Benjamin Wester University of Michigan CSE

  4. RSMs have high latency • Need many replies • Agreement • Geographic Distribution x=2 2 2 2 x=2 x=2 x=2 Benjamin Wester University of Michigan CSE

  5. Hide the Latency • Use speculative execution inside RSM • Speculate before consensus is reached • Without faults, any reply predicts consensus value • Let client continue after receiving one reply Benjamin Wester University of Michigan CSE

  6. Overview • Introduction • Improving RSMs with speculation • Application to PBFT • Performance • Conclusion Benjamin Wester University of Michigan CSE

  7. Speculative Execution in RSM • Continue processing while waiting Take Checkpoint Predict: 1 Speculate! Blocked Commit Rollback x=1 x=1 x=2 Benjamin Wester University of Michigan CSE

  8. Critical path: first reply • Completion latency less relevant • First reply latency sets critical path • Speed • Accuracy • Other desirable properties • Throughput • Stability under contention • Smaller number of replicas 1 1 Benjamin Wester University of Michigan CSE

  9. Requests while speculative while !check_lottery(): submit_tps() buy_corvette() Predict win? = yes • Hold request • Bad performance • Distributed commit/rollback • State tracking complex yes buy win? What do we do with this? Benjamin Wester University of Michigan CSE

  10. Explicitly encode dependencies as predicates No special request handling needed Replicas need to log past replies Local decision at replicas matches client Resolve speculations on the replicas while !check_lottery(): submit_tps() buy_corvette() Predict win? = yes win? = yes buy = keys yes keys yes buy buy if win?=yes: buy win? Benjamin Wester University of Michigan CSE

  11. Overview • Introduction • Improving RSMs with speculation • Application to PBFT • Performance • Conclusion Benjamin Wester University of Michigan CSE

  12. Practical BFT -CS [Castro and Liskov 1999] client primary f=1 Benjamin Wester University of Michigan CSE

  13. Additional Details • Tentative execution • PBFT/PBFT-CS complete in 4 phases • Read-only optimization • Accurate answer from backup replica • Failure threshold • Bound worst-case failure • Correctness Benjamin Wester University of Michigan CSE

  14. Overview • Introduction • Improving RSMs with speculation • Application to PBFT • Performance • Conclusion Benjamin Wester University of Michigan CSE

  15. Benchmarks • Shared counter • Simple checkpoint • No computation • NFS: Apache httpd build • Complex checkpoint • Significant computation Benjamin Wester University of Michigan CSE

  16. Topology Primary-local Primary-remote Uniform 2.5 or 15 ms Primary Benjamin Wester University of Michigan CSE

  17. Base case: no replication Primary-local Primary-remote Uniform 2.5 or 15 ms Benjamin Wester University of Michigan CSE

  18. Shared Counter Primary-local topology Benjamin Wester University of Michigan CSE

  19. Shared Counter Primary-local topology [Kotla et al. 07] Benjamin Wester University of Michigan CSE

  20. Shared Counter Uniform & Primary-remote topology Benjamin Wester University of Michigan CSE

  21. Shared Counter Uniform & Primary-remote topology Benjamin Wester University of Michigan CSE

  22. NFS: Apache build Primary-local topology Benjamin Wester University of Michigan CSE

  23. NFS: Apache build Uniform topology Benjamin Wester University of Michigan CSE

  24. NFS: Apache build Primary-remote topology Benjamin Wester University of Michigan CSE

  25. NFS: With Failure Primary-local topology (1% fail) Benjamin Wester University of Michigan CSE

  26. Throughput (Shared Counter) LAN topology Benjamin Wester University of Michigan CSE

  27. Conclusion • Integrate client speculation within RSMs • Predicated requests: performance without complexity • Clients less sensitive to latency between replicas • 5x speedup over non-speculative protocol Makes WAN deployments more practical Benjamin Wester University of Michigan CSE

More Related