1 / 16

SEDA: An Architecture for Well-Conditioned, Scalable Internet Services

SEDA: An Architecture for Well-Conditioned, Scalable Internet Services. OFFENCE. Presented by Changdae Kim and Jaeung Han. Other results about SEDA (1/4). Lower throughput than Apache and Flash.

oceana
Download Presentation

SEDA: An Architecture for Well-Conditioned, Scalable Internet Services

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. SEDA: An Architecture for Well-Conditioned,Scalable Internet Services OFFENCE Presented by Changdae Kim and Jaeung Han

  2. Other results about SEDA (1/4) Lower throughput than Apache and Flash K. Park and V. S. Pai. Connection conditioning: Architecture-independent support for simple, robust servers. In Network Systems Design and Implementation, 2006.

  3. Other results about SEDA (2/4) Is it scalable? K. Park and V. S. Pai. Connection conditioning: Architecture-independent support for simple, robust servers. In Network Systems Design and Implementation, 2006.

  4. Other results about SEDA (3/4) Lower Performance than thread-based servers • Capriccio: thread-based improved webserver • Flux: a language for programming high-performance servers B. Burns, K. Grimaldi, A. Kostadinov, E. Berger, and M. Corner. Flux: A language for programming high-performance servers. In Proceedings of the 2006 USENIX Annual Technical Conference, pages 129–142, 2006.

  5. Other results about SEDA (4/4) • Four possibilities: • SEDA can show good performance only with some specific hardware and kernel. • SEDA can be better only with some workloads. • SEDA paper does not tune other server architectures. • SEDA’s results in the paper is wrong.

  6. Scalable with Architecture? (1/3) • Thread is a friend of Multi-processor and SMT • Cache friendly: no migration is necessary • Scheduling is straightforward and it is enough • SEDA is not • Requires many migrations, or • Needs very complicated scheduling with each stage’s thread pool, or • N-copy approach: N copies of server with N processors N. Zeldovich, A. Yip, F. Dabek, R. T. Morris, D. Mazieres, and F. Kaashoek. Multiprocessor support for event-driven programs. In Proceedings of the USENIX 2003 Annual Technical Conference, June 2003. Thread 1 Thread 2 • Thread • 4 Stage 1 thread1 Stage 2 thread2 • Stage 2 • thread2 • Thread • 3 • Thread • 6 • Thread • 5 • Stage 3 • thread1 • Stage 3 • thread2 • Stage 4 • thread1 Thread-based SEDA

  7. Scalable with Architecture?(2/3) Low performance on SMP or SMT Y. Ruan, V. S. Pai, E. Nahum, and J. M. Tracey. Evaluating the impact of simultaneous multithreading on network servers using real hardware. In SIGMETRICS ’05: Proceedings of the 2005 ACM SIGMETRICS international conference on Measurement and modeling of computer systems, pages 315–326, New York, NY, USA, 2005. ACM Press.

  8. Scalable with Architecture?(3/3) Low Speedup with SMT Y. Ruan, V. S. Pai, E. Nahum, and J. M. Tracey. Evaluating the impact of simultaneous multithreading on network servers using real hardware. In SIGMETRICS ’05: Proceedings of the 2005 ACM SIGMETRICS international conference on Measurement and modeling of computer systems, pages 315–326, New York, NY, USA, 2005. ACM Press.

  9. Problems Are Not Inherent (1/4) • There is a duality between threaded and message-passing systems • Performance should be similar and depends on architectural support. • Thread-based system can be improved: • Restrictive control flow: all mechanisms in event-based system can be expressed more naturally with threads. • Heavy thread synchronization: the advantage from SEDA is really due to cooperative multitasking(i.e., no preemption), not event. • Ineffective state management: dynamic stack growth is possible. • Not optimized scheduling: The same scheduling tricks in event-based system can be applied. Lauer, H.C., Needham, R.M., "On the Duality of Operating Systems Structures," in Proc. Second International Symposium on Operating Systems, IRIA, Oct. 1978, reprinted in Operating Systems Review, 13,2 April 1979, pp. 3-19. R. von Behren, J. Condit, and E. Brewer. Why events are a bad idea (for high-concurrency servers). In Proc. HotOS-IX, May 2003.

  10. Problems Are Not Inherent(2/4) There is a possibility. R. von Behren, J. Condit, and E. Brewer. Why events are a bad idea (for high-concurrency servers). In Proc. HotOS-IX, May 2003.

  11. Problems Are Not Inherent(3/4) Knot(thread-based)shows similar performance and scalability. Rob von Behren, Jeremy Condit, Feng Zhou, George C. Necula, and Eric Brewer. Capriccio: Scalable Threads for Internet Services. In Proc. of the 19th ACM Symposium on Operating Systems Principles (SOSP), pages 268–281. ACM Press, 2003.

  12. Problems Are Not Inherent(4/4) • Event-based system has some problems: • Haboob(event-based) requires context switch more than 6 times as frequently as Knot(thread-based). • The proliferation of small modules – which is a natural outgrowth of the event programming model – creates a large number of module crossings and queuing operations. • Event-based systems require various forms of run-time dispatch. This is related to the problem of ambiguous control flow. • This reduces opportunities for compiler optimizations and increases CPU pipeline stalls. • In the perspective of the programmer, this is hard to understand and error prone.

  13. Recent Hybrid Approaches (1/3) • Threads vs. Events • In the more recent research, hybrid approaches or more optimized event-based systems show better performance

  14. Recent Hybrid Approaches(2/3) • WatPipe • SEDA-based hybrid approach • Shortened pipeline • No dynamic resource controllers • No explicit event queue • μSERVER • optimized event-based D. Pariag, T. Brecht, A. Harji, P. Buhr, and A. Shukla. Comparing the performance of web server architectures. In Proc. 2007 EuroSys, March 2007.

  15. Recent Hybrid Approaches(3/3) • Capriccio: thread-based approach • Tame: hybrid approach M. Krohn, E. Kohler, and M. F. Kaashoek. Events can make sense. In Proc. 2007 USENIX, June 2007.

  16. Conclusion • Threads  Events • Performance, Expressiveness • Threads > Events • Complexity, Manageability • Thread < Events • Memory space, # of threads • For now, hybrid approach is best • Threads vs. Events doesn’t end CurrentThreads What will be here? Ease of Programming Current Events Current Threads Performance

More Related