1. SEDA: An Architecture for Well-Conditioned, Scalable Internet Services Presented by Changdae Kim and Jaeung Han OFFENCE

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

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

4. Capriccio: thread-based improved webserver Flux: a language for programming high-performance servers Other results about SEDA (3/4) 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. Lower Performance than thread-based servers Lower Performance than thread-based servers

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. 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. 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 Thread 2 Thread 4 Thread 1 Thread 3 Thread 6 Thread 5 Thread-based Stage 2 thread2 Stage 2 thread2 Stage 1 thread1 Stage 3 thread1 Stage 3 thread2 Stage 4 thread1 SEDA

7. Scalable with Architecture? (2/3) 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. Low performance on SMP or SMT Low performance on SMP or SMT

8. Scalable with Architecture? (3/3) 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. Low Speedup with SMT Low Speedup with SMT

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. ThreadsEvents Monitors Exported functions Call/return and fork/join Wait on condition variable Event handler & queue Events accepted Send message / await reply Wait for new messages 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) R. von Behren, J. Condit, and E. Brewer. Why events are a bad idea (for high-concurrency servers). In Proc. HotOS-IX, May 2003. There is a possibility. There is a possibility.

11. Problems Are Not Inherent (3/4) 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. Knot (thread-based) shows similar performance and scalability. Knot (thread-based) shows similar performance and scalability.

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) D. Pariag, T. Brecht, A. Harji, P. Buhr, and A. Shukla. Comparing the performance of web server architectures. In Proc. 2007 EuroSys, March 2007. WatPipe SEDA-based hybrid approach Shortened pipeline No dynamic resource controllers No explicit event queue μSERVER optimized event-based

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

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 Performance Ease of Programming Current Threads Current Events What will be here?