SEDA: An Architecture for Well-Conditioned, Scalable Internet Services
Matt Welsh, David Culler, and Eric Brewer

SEDA addresses an important need in Internet services: how to manage
resources and maintain fairness in spite of bursty traffic and overload.
SEDA stands for staged event-driven architecture. Its architecture is
similar to the Click router; it consists of a set of stages, each with a
specific function, connected by queues. Stages can communicate with each
other either directly or through queues. Each queue is serviced by a small
thread pool that continuously loops and processes events. The events may
be OS-related, such as timers and disk I/O, or may be application-related.
This model requires nonblocking threads and I/O.

SEDA uses dynamic resource controllers to adjust resource usage in
response to observed activity. For example, the number of threads in each
pool can be dynamically regulated according to the length of the queue.
The dynamic controllers are not aware of the underlying resource
management policies of the operating system.

The results in the paper show that SEDA performs comparably to Apache and
Flash with both server-to-client and peer-to-peer applications. One
important difference is that SEDA prioritizes fairness over low response
times. Under large loads, Apache serves some clients very quickly and
makes others wait up to 93 seconds. SEDA degrades performance for all
clients, but has a maximum response time of 3.8 seconds. One bottleneck in
SEDA is queueing delays. To avoid this problem in the Haboob benchmark, a
load-shedding controller was added to the system. The authors suggest some
alternatives, such as degrading performance or redirecting users to a less
loaded node, but there does not seem to be a good solution to this
problem. Although the problem is "solved" using dynamic control, the
authors point out that it can be difficult to figure out when dynamic
control is needed and how to apply it. Nevertheless, the ability to use
dynamic control and the decomposition of the architecture into stages
simplifies code and provides the possibility of a fairer, more scalable
Internet service.