1 / 17

Paper Review of Why Events Are A Bad Idea (for high-concurrency servers) Rob von Behren, Jeremy Condit and Eric Brewer

Paper Review of Why Events Are A Bad Idea (for high-concurrency servers) Rob von Behren, Jeremy Condit and Eric Brewer. By Anandhi Sundaram. THE STAGE. Highly Concurrent Applications Internet Servers Transaction Processing Databases Challenges Posed

bing
Download Presentation

Paper Review of Why Events Are A Bad Idea (for high-concurrency servers) Rob von Behren, Jeremy Condit and Eric Brewer

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. Paper Review of Why Events Are A Bad Idea(for high-concurrency servers)Rob von Behren, Jeremy Condit and Eric Brewer By Anandhi Sundaram

  2. THE STAGE • Highly Concurrent Applications • Internet Servers • Transaction Processing Databases • Challenges Posed • Large numbers of Concurrent tasks, require scalable Data Structures • Operate near max capacity, Resource Contention, Scheduling Sensitivity • Inevitable Overload, must be handled to avoid thrashing, well-conditioned • Race Conditions, Code Complexity Ideal Peak: some resource at max Performance Overload: someresource thrashing Load (concurrent tasks) CS533 - Concepts of Operating Systems

  3. Events are Better • Recent Arguments for Events • Inexpensive synchronization due to co-operative multitasking • Lower Overhead for managing state (no stacks) • Better scheduling and locality • More Flexible Control Flow • True But • All above properties can be implemented in Threads • Problem is with Thread Implementations, and not Threads CS533 - Concepts of Operating Systems

  4. Overcoming the “Problems” with Threads • Performance • Criticism: Threads don’t perform well for high concurrency • Reasons : • Presence of O(n) thread operations • High Context Switch overhead • Response • Avoid O(n) operations • Co-operative Multi-tasking CS533 - Concepts of Operating Systems

  5. Simple Scalability Test • Slightly modified GNU Pth • Removed O(n) operations from scheduler • Thread-per-task Vs Single Thread • Same Performance CS533 - Concepts of Operating Systems

  6. Overcoming the “Problems” with Threads • Control Flow • Criticism: Threads have restrictive Control flow • Response: Code Structure of Web Server and applications fall under three simple categories - call/return - Parallel Calls - Pipeline Threads express the above more naturally Complex Patterns are unnatural, hard to understand, Error-prone CS533 - Concepts of Operating Systems

  7. Overcoming the “Problems” with Threads • Synchronization • Criticism: Thread Synchronization mechanisms are too heavyweight • Response : • Co-operative Multitasking works for threads too • Compiler Support in MultiProcessor Systems CS533 - Concepts of Operating Systems

  8. Overcoming the “Problems” with Threads • State Management • Criticism: Thread Stacks are an ineffective way to manage live state • Response : • Compiler support for Dynamic Stack Growth • Compiler support for better Live State Management • Entire frame could be popped in case of tail call • Variables with overlapping lifetimes could be moved off stack • Compiler warns about inefficiency CS533 - Concepts of Operating Systems

  9. Overcoming the “Problems” with Threads • Scheduling • Criticism: Thread schedulers are too generic • Can’t use application-specific information • Response • 2D scheduling: task & program location • Threads schedule based on task only • Events schedule by location (e.g. SEDA) • Allows batching, prediction for SRCT • Resource Aware Scheduling in Capriccio • Runtime system tracks current location • Block graph allows prediction Task Program Location Events Threads CS533 - Concepts of Operating Systems

  10. The Case For Threads • Observations About Modern Servers • Concurrent Requests are Largely Independent • Code handling each request is Sequential • Threads – A more Natural Programming Model • Express Better Control Flow • Automatic State Management • Exception Handling Easier in Threads CS533 - Concepts of Operating Systems

  11. The Case for Threads • Lots of Infrastructure for Threads • Debuggers, Languages, Compilers • Consequences • More amenable to Analysis • Less effort to get working systems CS533 - Concepts of Operating Systems

  12. The Duality Argument • Two Models are Duals of Each other • With Good Practices both approaches should yield equivalent performance • No inherent problem with threads! • Equivalent Good Thread implementations possible • Thread-based approach is preferrable • More natural Programming Model • Co-operative multitasking threads • Compiler Support CS533 - Concepts of Operating Systems

  13. Evaluation • User-level cooperative threads package • Minimal context switching • Converts Blocking I/O to Asynchronous I/O • No O(n) operations • Support > 100K threads • Simple web server: Knot • Knot-A : Favors accepting new clients over processing • Knot-C : Favors processing existing clients over accepting new clients CS533 - Concepts of Operating Systems

  14. 900 800 KnotC (Favor Connections) KnotA (Favor Accept) 700 Haboob Mbits / second 600 500 400 300 200 100 0 1 4 16 64 256 1024 4096 16384 Concurrent Clients Evaluation • Compared performance of Haboob with Knot-A, Knot-C • The Steady-state bandwidth of • Knot-C higher than Haboob • Performance degradation of Knot-A, Haboob is due to poor scalability of poll() • Haboob ran out of memory with 16384 clients CS533 - Concepts of Operating Systems

  15. Evaluation • Reasons for Haboob’s Poor Performance • Haboob’s context switches 6X times as Knot • Large number of queueing operations • Relies heavily on garbage collection • Ambiguous control flow, reduces compiler optimization, increases CPU-stalls Conclusion : A well-designed thread package can achieve the same scaling behaviour as a well-designed event system. CS533 - Concepts of Operating Systems

  16. References • 1. Why Events are a Bad Idea (for high-concurrency servers), Rob von Behren, Jeremy Condit, and Eric Brewer. In Proceedings of the 10th Workshop on Hot Topics in Operating Systems (HotOS IX), Lihue, Hawaii, May 2003. [pdf] http://warthog.cs.berkeley.edu/pubs/threads_hotos_2003_slides.ppt • 2. On the Duality of Operating System Structures, Hugh C.Lauer, Roger M.Needham • 3. Event Driven Programming for Robust Software, Frank Dabek, Nickolai Zeldovich, Frans Kaashoek, David Mazieres, Robert Morris • 4. SEDA: An Architecture for Well-Conditioned, Scalable Internet Services, Matt Welsh, David Culler, and Eric Brewer • 5. Capriccio: Scalable Threads for Internet Services, Rob von Behren, Jeremy Condit, Feng Zhou, George C. Necula, and Eric Brewer. In Proceedings of the Ninteenth Symposium on Operating System Principles (SOSP-19), Lake George, New York. October 2003 http://warthog.cs.berkeley.edu/pubs/capriccio-sosp-2003.pdf CS533 - Concepts of Operating Systems

  17. References • GNU Pth – The GNU Portable Threads http://www.gnu.org/software/pth CS533 - Concepts of Operating Systems

More Related