A single-process server that waits for one client to finish sending a request can leave every other client waiting. That client might respond in 1 ms—or take an hour. Asynchronous programming lets the server attend to other connections instead of making slow input hold up all requests. section 3.1
This is especially useful when many requests involve slow I/O but little processing, as is common for web servers. It can serve concurrent requests efficiently without parallel execution. Asynchronous execution is a separate choice from using one thread, multiple threads, or multiple processes. section 3.1 section 3.6
Receiving MapReduce requests
Consider a server that accepts client connections and receives both data and code for MapReduce requests. The first problem is receiving those requests without letting a slow client make other connections unresponsive; processing the requests is a separate concern. section 3.1
Figure 3.2 Several architectures covering synchronous single-process/thread, synchronous multiprocess, and asynchronous single-process implementations for a server
Compare a blocking single-process server, a synchronous multiprocess server, and an asynchronous single-process server to see why handling concurrent connections does not require parallel execution. section 3.1
