Why%20Events%20Are%20A%20Bad%20Idea%20(for%20high-concurrency%20servers) - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

Why%20Events%20Are%20A%20Bad%20Idea%20(for%20high-concurrency%20servers)

Description:

Why Events Are A Bad Idea (for high-concurrency servers) By Rob von Behren, Jeremy Condit and Eric Brewer Arguments For Using Events Inexpensive synchronization Lower ... – PowerPoint PPT presentation

Number of Views:45
Avg rating:3.0/5.0
Slides: 16
Provided by: Dway89
Learn more at: http://www.cs.pdx.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Why%20Events%20Are%20A%20Bad%20Idea%20(for%20high-concurrency%20servers)


1
Why Events Are A Bad Idea (for high-concurrency
servers)
  • By
  • Rob von Behren, Jeremy Condit and Eric Brewer

2
Arguments For Using Events
  • Inexpensive synchronization
  • Lower overhead for managing state
  • Better scheduling and locality
  • More flexible control flow

3
Arguments For Using Threads
  • More natural for high-concurrency servers
  • Threads can be improved to perform just as well
    as events
  • Threads are more easily optimized by compilers

4
Events Versus Threads
  • Lauer and Needham
  • Direct mapping

Events Threads
Event handlers Monitors
Events accepted by a handler Functions exported by a module
SendMessage / AwaitReply Procedure call, or fork/join
SendReply Return from a procedure
Waiting for messages Waiting on condition variables
5
Events Versus Threads
  • Preservation of performance
  • Need equally good implementations
  • primitives
  • Use whichever is more natural

6
Problems with Threads
  • Performance
  • High overhead
  • Context switches
  • Restrictive Flow Control
  • Forces linear programming style
  • Synchronization
  • Expensive (events get it for free?)

7
Problems with Threads
  • State Management
  • Thread stack ineffective (overflow vs. wasted
    space)
  • Event programmers manage state by hand
  • Scheduling
  • Virtual processor model prevents optimal
    scheduling decisions

8
Thread Benefits
  • Flow Control
  • No need for stack ripping
  • Allows a more natural style
  • Exception Handling
  • Simpler to do with threads
  • Easier to track live states (no need for garbage
    collection)
  • Existing Systems
  • Threads used in existing event-driven systems
  • Used for error recovery, other complex areas

9
Improving Threads
  • Improve thread packages
  • Compiler support
  • Dynamic stack growth
  • Stack size usually fixed
  • Can possibly overflow
  • Might waste space
  • Allow compiler to determine the stack size
  • Java Virtual Machine stack

10
Compiler support
  • Live state management
  • Again need compiler help
  • Pop temporary variables
  • Frame can be popped for tail calls
  • Reorder variables to allow dead variable to be
    freed
  • Warn programmer if a lot of state is being held
  • Synchronization
  • Warnings about data races
  • Indicate which sections can run concurrently

11
Implementation
  • User-level threads
  • Cannot preempt each other
  • Must yield
  • Each thread will run to completion
  • Coroutines to minimize cost of context switching
  • Context switches become calls to this library

12
Implementation
  • Asynchronous I/O
  • Cannot yield if blocking on I/O
  • Sounds like events
  • Poll indicates EVENTS that have happened to
    certain file descriptors
  • Scheduling policies
  • Favor active connections
  • Favor new connections

13
Results
  • Knot (Connections) 700 Mbit/s
  • Haboob (Max) 500 Mbit/s
  • Becomes CPU limited
  • More context switches than Knot
  • Knot (Accepts) in-between
  • More closely matches Haboobs policy

14
Test Fairness
  • Uses a small workload
  • Ran Haboob using JIT
  • Knot was written in?
  • Knot does not reallocate resources

15
Reasons You Might Need Threads
  • For high-concurrency
  • Natural flow control
  • Easier exception handling
  • Allows implementation of more complex systems
About PowerShow.com