Difference between revisions of "Continuations in Servers"
(2 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
− | Hiroshi Yamauchi, Google | + | ;Speaker: Hiroshi Yamauchi, Google |
+ | ;Resources: [[Media:ContinuationInServers.pdf | Slides]] | ||
+ | |||
+ | ===Abstract=== | ||
We are looking at a problem in servers about scalability vs. | We are looking at a problem in servers about scalability vs. |
Latest revision as of 17:53, 27 August 2010
- Speaker
- Hiroshi Yamauchi, Google
- Resources
- Slides
Abstract
We are looking at a problem in servers about scalability vs. productivity. There are two types of architectures: synchronous (aka blocking, 'thread-per-request') and asynchronous (aka non-blocking, 'select-server' style, event-driven) servers. The key distinction lies in how threads are mapped to requests and whether to block or not in network I/O (eg RPC or database access). The former is better in terms of productivity because the code gets simpler. The latter is better in scalability because a thread does not have to be tied to each request. We are investigating a continuation-based solution that gives us the best of both worlds: simpler code and better scalability. A synthetic rpc server has been 'converted' to use continuations and showed good performance. An experiment with a production server has been ongoing. We've been using a modified version of the old MLVM callcc patches.