The Internet and the World Wide Web stress operating systems in ways that original OS designers never anticipated. When you run a popular Web site, thousands or tens of thousands of people, located all over the world, can try to contact your computer every second, looking for data. The operating system and an application called a Web server must cooperate to serve as many of these requests as possible. The server and OS are often in the process of responding to many requests at once! (We call these programs "servers" because they respond to other computers' requests by delivering data, just like servers in restaurants respond to diners' requests by delivering food.)
It's important to realize that most Web servers have a very simple job -- they just read files from disk and send them over the network. A lot of issues that are important for other kinds of servers, such as databases and network file systems, may not come up. Responding to a request takes little CPU time; there's little need for locking, since requests are almost all reads; and so forth. So you'd think that even a stupid Web server would run quickly.
No such luck. It's easy to write a slow Web server. Because Web servers are so simple at the application level, they tend to highlight inefficiencies in the OS, and in the interface between the OS and the application. Thus, a lot of problematic aspects of server and OS design have been ironed out as we've learned to build fast Web servers.
This week's paper describes one of the first, and still one of the best, truly fast Web servers: Flash.
This paper is pretty different from the Therac-25 paper. Leveson and Turner wrote for a general audience; Pai, Druschel and Zwaenepoel wrote for the USENIX conference, whose audience likes to hear about implementation details. Papers like this aren't easy to read even for professionals. Don't worry about it! The paper has high-level ideas as well as details, and you should be able to get the high-level ideas without too much trouble. (You may want to start with Sections 2 through 4, and then go back and read the introduction.) Try not to get bogged down in the details, and focus on the high-level issues: How do the authors build a fast Web server? And how do the different Web server architectures really compare?
The Flash paper describes four server architectures: multi-process (MP), multi-threaded (MT), single-process event-driven (SPED), and asymmetric multi-process event-driven (AMPED). Pick two of these architectures and compare them along two dimensions:
- Sources of overhead. What kinds of performance bottlenecks matter in the architecture?
- Ease of programming. What kinds of difficulties must the programmer face when writing a program in the architecture?
Also, how important do you think these factors are relative to one another?
Restriction: Pick one multi-thread/process architecture, and one event-driven architecture. You may not write about the combinations MP+MT or SPED+AMPED.
If you don't know how to start thinking about ease of programming, try thinking about the pictures of how requests are processed in each architecture (Figures 2-5). How do these pictures compare with the abstract request model in Figure 1? Would you want the architectures to match the abstract model, or not? There are also a couple statements about programmability in the paper.