SEDA – Staged Event-Driven Architecture

Slides:



Advertisements
Similar presentations
Scheduling in Web Server Clusters CS 260 LECTURE 3 From: IBM Technical Report.
Advertisements

Dynamic Task Assignment Load Index for Geographically Distributed Web Services PhD Research Proposal By: Dhiah Al-Shammary Supervised.
Efficient Event-based Resource Discovery Wei Yan*, Songlin Hu*, Vinod Muthusamy +, Hans-Arno Jacobsen +, Li Zha* * Chinese Academy of Sciences, Beijing.
Web Server Benchmarking Using the Internet Protocol Traffic and Network Emulator Carey Williamson, Rob Simmonds, Martin Arlitt et al. University of Calgary.
Capriccio: Scalable Threads for Internet Services Rob von Behren, Jeremy Condit, Feng Zhou, Geroge Necula and Eric Brewer University of California at Berkeley.
Flash: An efficient and portable Web server Authors: Vivek S. Pai, Peter Druschel, Willy Zwaenepoel Presented at the Usenix Technical Conference, June.
1 SEDA: An Architecture for Well- Conditioned, Scalable Internet Services Matt Welsh, David Culler, and Eric Brewer Computer Science Division University.
CS533 Concepts of Operating Systems Jonathan Walpole.
SEDA: An Architecture for Well- Conditioned, Scalable Internet Services Matt Welsh, David Culler, and Eric Brewer Computer Science Division University.
Concurrency, Thread and Event CS6410 Sept 6, 2011 Ji-Yong Shin.
CS533 Concepts of Operating Systems Class 5 Event-Based Systems.
SEDA: An Architecture for Well-Conditioned, Scalable Internet Services Matt Welsh, David Culler, and Eric Brewer Computer Science Division University of.
Capriccio: Scalable Threads for Internet Services ( by Behren, Condit, Zhou, Necula, Brewer ) Presented by Alex Sherman and Sarita Bafna.
Computer Science Lecture 6, page 1 CS677: Distributed OS Processes and Threads Processes and their scheduling Multiprocessor scheduling Threads Distributed.
CS 623 Lecture #9 Yen-Yu Chen Utku Irmak. Papers to be read Better operating system features for faster network servers.Better operating system features.
Capriccio: Scalable Threads for Internet Services Rob von Behren, Jeremy Condit, Feng Zhou, Geroge Necula and Eric Brewer University of California at Berkeley.
Computer Science Scalability of Linux Event-Dispatch Mechanisms Abhishek Chandra University of Massachusetts Amherst David Mosberger Hewlett Packard Labs.
CS533 Concepts of Operating Systems Class 5 Event-Based Systems.
Why Events Are a Bad Idea (for high-concurrency servers) Author: Rob von Behren, Jeremy Condit and Eric Brewer Presenter: Wenhao Xu Other References: [1]
Computer Science Lecture 2, page 1 CS677: Distributed OS Last Class: Introduction Distributed Systems – A collection of independent computers that appears.
Kyushu University Graduate School of Information Science and Electrical Engineering Department of Advanced Information Technology Supervisor: Professor.
“Why Events are a Bad Idea (For high-concurrency servers)” Paper by Rob von Behren, Jeremy Condit and Eric Brewer, May 2003 Presentation by Loren Davis,
CS533 Concepts of Operating Systems Class 2 Thread vs Event-Based Programming.
Kerim KORKMAZ A. Tolga KILINÇ H. Özgür BATUR Berkan KURTOĞLU.
CS533 Concepts of Operating Systems Class 2 The Duality of Threads and Events.
Adaptive Content Delivery for Scalable Web Servers Authors: Rahul Pradhan and Mark Claypool Presented by: David Finkel Computer Science Department Worcester.
SEDA: An Architecture for Well-Conditioned, Scalable Internet Services
SEDA: An Architecture for Well-Conditioned, Scalable Internet Services by, Matt Welsh, David Culler, and Eric Brewer Computer Science Division University.
Designing Efficient Systems Services and Primitives for Next-Generation Data-Centers K. Vaidyanathan, S. Narravula, P. Balaji and D. K. Panda Network Based.
SEDA: An Architecture for Well-Conditioned, Scalable Internet Services
Application-Layer Anycasting By Samarat Bhattacharjee et al. Presented by Matt Miller September 30, 2002.
Adaptive Overload Control for Busy Internet Servers Matt Welsh and David Culler USENIX Symposium on Internet Technologies and Systems (USITS) 2003 Alex.
Dave Archer - CS533 - Spring On the Duality of Operating System Structures Hugh C. Lauer, Roger M. Needham.
SEDA: An Architecture for Well-Conditioned, Scalable Internet Services Presented by Changdae Kim and Jaeung Han OFFENCE.
© Lindsay Bradford1 Scaling Dynamic Web Content Provision Using Elapsed-Time- Based Content Degradation Lindsay Bradford, Stephen Milliner and.
A Measurement Based Memory Performance Evaluation of High Throughput Servers Garba Isa Yau Department of Computer Engineering King Fahd University of Petroleum.
Background: Operating Systems Brad Karp UCL Computer Science CS GZ03 / M th November, 2008.
Computer Science 1 Adaptive Overload Control for Busy Internet Servers Matt Welsh and David Culler USITS 2003 Presented by: Bhuvan Urgaonkar.
1 Admission Control and Request Scheduling in E-Commerce Web Sites Sameh Elnikety, EPFL Erich Nahum, IBM Watson John Tracey, IBM Watson Willy Zwaenepoel,
Middleware Services. Functions of Middleware Encapsulation Protection Concurrent processing Communication Scheduling.
5204 – Operating Systems Threads vs. Events. 2 CS 5204 – Operating Systems Forms of task management serial preemptivecooperative (yield) (interrupt)
Measuring the Capacity of a Web Server USENIX Sympo. on Internet Tech. and Sys. ‘ Koo-Min Ahn.
Department of Computer Science and Software Engineering
Presenting: Why Events Are A “Bad” Idea ( for high-concurrency servers) Paper by: Behren, Condit and Brewer, 2003 Presented by: Rania Elnaggar 1/30/2008.
1 Cooperative Task Management without Manual Stack Management or Event-driven Programming is not the Opposite of Threaded Programming Atul Adya, Jon Howell,
SEDA: An Architecture for Well-Conditioned, Scalable Internet Services Matt Welsh, David Culler, and Eric Brewer Computer Science Division University of.
By: Rob von Behren, Jeremy Condit and Eric Brewer 2003 Presenter: Farnoosh MoshirFatemi Jan
SEDA An architecture for Well-Conditioned, scalable Internet Services Matt Welsh, David Culler, and Eric Brewer University of California, Berkeley Symposium.
Threads versus Events CSE451 Andrew Whitaker. This Class Threads vs. events is an ongoing debate  So, neat-and-tidy answers aren’t necessarily available.
SHADOWSTREAM: PERFORMANCE EVALUATION AS A CAPABILITY IN PRODUCTION INTERNET LIVE STREAM NETWORK ACM SIGCOMM CING-YU CHU.
1 Why Events Are A Bad Idea (for high-concurrency servers) By Rob von Behren, Jeremy Condit and Eric Brewer (May 2003) CS533 – Spring 2006 – DONG, QIN.
An Efficient Threading Model to Boost Server Performance Anupam Chanda.
CS533 Concepts of Operating Systems Jonathan Walpole.
SEDA: An Architecture for Scalable, Well-Conditioned Internet Services
Paper Review of Why Events Are A Bad Idea (for high-concurrency servers) Rob von Behren, Jeremy Condit and Eric Brewer By Anandhi Sundaram.
SEDA. How We Got Here On Tuesday we were talking about Multics and Unix. Fast forward years. How has the OS (e.g., Linux) changed? Some of Multics.
Capriccio:Scalable Threads for Internet Services
Last Class: Introduction
SEDA: An Architecture for Scalable, Well-Conditioned Internet Services
Threads vs. Events SEDA – An Event Model 5204 – Operating Systems.
Why Events Are A Bad Idea (for high-concurrency servers)
The Multikernel: A New OS Architecture for Scalable Multicore Systems
Processes and Threads Processes and their scheduling
Chapter 4: Multithreaded Programming
Presenter: Godmar Back
Capriccio – A Thread Model
On the Duality of Operating System Structures
Admission Control and Request Scheduling in E-Commerce Web Sites
Why Events Are a Bad Idea (for high concurrency servers)
SEDA: An Architecture for Well-Conditioned, Scalable Internet Services
Presentation transcript:

SEDA – Staged Event-Driven Architecture SEDA: An Architecture for well-conditioned scalable internet services. Matt Welsh, David Culler & Eric Brewer Presented by Rahul Agarwal Note keywords - UNDERLINED – will come to these

Overview Motivation Key Points Thread vs. Event concurrency SEDA Experimental Evaluation My Evaluation Questions to Consider

Authors Main Author Culler & Brewer - Advisors Matt Welsh’s PhD thesis at UC Berkeley Now Assistant Professor in CS Dept at Harvard Currently working on wireless sensor networks Research interests in OS, Networks and Large Scale Distributed Systems Culler & Brewer - Advisors Even written a book on Linux

Motivation High demand for web content – for example concurrent millions of users for Yahoo Load Spikes – “Slashdot Effect” Over provisioning support not feasible financially and events unannounced Web services getting more complex, requiring maximum server performance High demand – google, news sites etc Spikes – but not many users before or after a significant event, 9/11, Mars lander Complexity Services getting complex Logic changes rapidly Services hosted on general purpose machines rather than carefully engineered hardware

Motivation – Well-conditioned Service A well-conditioned service behave like a simple pipeline As offered load increase throughput increases proportionally When saturated it does not degrade throughput – graceful degradation Want to provide a well-conditioned service

Pipelining Pipeline has stages Speedup, Have more stages – smaller size of stage Bottlenecks? – dryer too slow Dependency – cant fold until dried Dryer takes 60min, Washer 30min – implications, queues will form In case of SEDA resources can be reallocated, dryer can change to washer! How can we improve throughput in a pipeline? Potential problems?

Key Points Application as a network of event-driven stages connected by queues Dynamic Resource Controllers Automatic load tuning Thread pool sizing Event Batching Adaptive load shedding Support massive concurrency and prevent resources from being overcommitted Overview of SEDA Will discuss each point in detail

Thread-Based vs. Event-Based Concurrency Thread-per-request OS switches and overlaps computation and I/O Synchronization required Performance Degradation Eg: RPC, RMI, DCOM Overcome by more control to OS Eg: SPIN, Exokernel, Nemesis Overcome by reuse of threads Eg: Apache, IIS, Netscape… everyone! Event One thread per CPU (controller) Process events generated by apps and kernel Each task implemented as a FSM with transitions triggered by events Pipelining! Eg: Flash, Zeus, JAWS Harder to modularize and engineer We are talking about internet services In this context…. THREAD Degradation by cache misses, scheduling overhead, lock contention due to too many threads More control to OS -> let OS see more Reuse of threads -> bounded thread pools .. BEA weblogic…IBM websphere, unfairness EVENT Stages Each stage has its own thread

Thread-Based vs. Event-Based Concurrency (Contd.) FSM – Finite state machines Thread – context switch overhead, contended locks, throughput meltdown, increase in response time One thread per request vs. One active stage per request THESE ARE FROM INITIAL INVESTIGATION - Note change in throughput Note increase in latency of both – however at much larger number for event-based NOTE DIFFERENT SCALES ON AXIS

Thread-Based vs. Event-Based Concurrency (Contd.) FSM – Finite state machines Thread – context switch overhead, contended locks, throughput meltdown, increase in response time One thread per request vs. One active stage per request THESE ARE FROM INITIAL INVESTIGATION - Note change in throughput Note increase in latency of both – however at much larger number for event-based NOTE DIFFERENT SCALES ON AXIS

SEDA FSM for a simple HTTP server request Haboob server – some edges excluded…. Queues introduce explicit control boundaries Stages are non-blocking internally, may block between stages Tread pool not exposed to applications – controller for it Thread pool size – adjust depending on length of queue SEDA assumes message passing does not require specialized support Events processed – if next stage is slow adjust output rate (Batching control) SEDA prototype implementation known as Sandstorm

SEDA - Stage Each stage has its own thread pool Controller adjusts resources Controller may set “admission control policy” Threshold, rate-control, load shedding Adjust thread pool size Adjust number of events processed

Overload Management Resource Containment Admission Control Static method Usually set by admin Admission Control Parameter based Static or dynamically adjusted Control-theoretic approach Service Degradation Deliver lower fidelity Service Ways to control overload Resource containment – static Apache sets thread limit Unfair (Explain what fairness means) No response to client indicating what is going on NEXT SLIDE what we are interested in

SEDA Admission Control Policy Using 90th percentile of set response time as performance metric Adaptive admission control Uses user classes (IPs, HTTP header info) Uses token bucket traffic shaper Possible to use drop-tail, FIFO, RED or other algorithms What we are interested in GOAL - Response time should be in above the 90th percentile Classes to prioritize certain users over others CHART: For Arashi email service Load spike of 1000 users at t=70 and leaves at t=150 Note how admission rate increases at t=75 as then again at 140

Event-driven programming Benefits  Applications can map cleanly into modules Each stage self-contained Typically little/no data sharing Challenges Determining stages Stages can block Managing continuations between stages Tracking events

Software Contribution Sandstorm: SEDA Framework NBIO: Non-blocking I/O implementation Haboob: Implementation of a web-server aTLS: library for SSL and TLS support All Java implementations, NBIO uses JNI Last updated July 2002 Consists of the following Sandstorm is basically the framework – implementing and connecting stages, queue management etc Atls – support for SSL+TLS NBIO – non blocking IO implementation, wasn’t supported in Java, now standard feature Haboob – Web server implementation – faster than apache Also an email service called Arashi

Experimental Evaluation Throughput vs. #Clients Haboob web-server Static and dynamic file load – SpecWEB99 benchmark 1 to 1024 clients Total files size 3.31Gb Memory Cache of 200Mb Industry standard benchmark 10% improvement in throughput

Throughput and Fairness vs. #Clients Evaluation (Contd.) Throughput and Fairness vs. #Clients Jain’s Fairness Index Equality of services to all clients Suppose server can support 100 requests Totally fair if it processes 10 requests of each Unfair if say it processes 20 requests each for 5 users Jain Fairness index – treating all clients equally Show on board

Cumulative response time distribution for 1024 clients Evaluation (Contd.) Cumulative response time distribution for 1024 clients cumulative response time distribution for Haboob, Apache, and Flash with 1024 clients. While Apache and Flash exhibit a high frequency of low response times, there is a heavy tail, with the maximum response time corresponding to several minutes. This is due to exponential backoff in the TCP SYN retransmit timer: Apache accepts only 150 connections, and Flash accepts only 506, despite 1024 clients requesting service. Note the log scale on the horizontal axis.

Evaluation (Contd.) Gnutella packet router Non-traditional internet service, routing P2P packets Ping: Discover other nodes Query: Search for files being served Show non-traditional service Show dynamic thread pools

Summary Notion of stages Explicit event queues Dynamic resource controllers + Improved performance + Well-conditioned services + Scalability Main ideas and advantages

My Evaluation Increased performance at higher loads which was the motivation Marginal increase in throughput but significantly more fair for higher loads Throughput does not degrade when resources exhausted Response times of other servers better at lower loads

My Evaluation In context of duality of OS structures (Lauer & Needham) SEDA is message-oriented Message and Procedure oriented can be directly mapped, however independent of the application under consideration can performance indeed be similar? We will see how Capriccio does this – but no simple mapping!

Questions to consider SEDA is so good but the whole world (Apache, IIS, BEA, IBM, Netscape…) still uses thread-based servers? In real world scenarios how often are there load spikes, should goal be to increase average case performance instead? Is throughput or fairness a better metric? Being faster “despite” being in Java a bias or poor choice of language?

References Welsh, M., Culler, D., Brewer, E. (2001). SEDA: An architecture for well-conditioned, scalable internet services. Proceeding of 18th SOSP, Banff, Canada, October 2001 SEDA Project http://sourceforge.net/projects/seda Welsh, M. (2002). An architecture for well-conditioned, scalable internet services. PhD Thesis, University of California, Berkeley Welsh, M. (2001) SEDA: An architecture for well-conditioned, scalable internet services. Presentation at 18th SOSP, Lake Louise, Canada, October 24, 2001 Welsh, M., Culler, D., Adaptive overload control for busy internet servers. Unpublished. Pipelining: http://cse.stanford.edu/class/sophomore-college/projects-00/risc/pipelining/ Lauer, H. C. & Needham, R. M. (1978). On the duality of operating systems structures. In proceedings 2nd International Symposium on Operating Systems, IRIA, October 1978, reprinted in Operating Systems Review, 13, 2 April 1979, pp 3-19. Behren, R. et al. (2003). Capricco: Scalable Threads for Internet Services. Proc SOSP, New York, October 2003