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

Presented by Changdae Kim and Jaeung Han

OFFENCE

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 throughputthan Apache and Flash

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?

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

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.

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

Thread2

Thread4

Thread 1

Thread3

Thread6

Thread5

Thread-based

Stage 2thread2

Stage 2thread2

Stage 1 thread1

Stage 3thread1

Stage 3thread2

Stage 4thread1

SEDA

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 performanceon SMP or SMT

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 Speedupwith SMT

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.

Threads Events 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.

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 isa possibility.

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) showssimilar performance

and scalability.

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.

Recent Hybrid Approaches (1/3)

Threads vs. Events In the more recent research, hybrid

approaches or more optimized event-based systems show better performance

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

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

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 P

rogr

amm

ing

CurrentThreads

Current Threads

Current Events

What willbe here?