Difference between revisions of "Continuations in Servers"
(New page: 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-...) |
|||
| (3 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| + | ;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. | ||
productivity. There are two types of architectures: synchronous (aka | productivity. There are two types of architectures: synchronous (aka | ||
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.
