Check out the new USENIX Web site. next up previous
Next: Flashpache Up: Understanding and Addressing Blocking-Induced Previous: Quantifying Service Inversion

The New Servers & Results


In this section we describe our solution and evaluate the resulting systems. We analyze the effects on capacity, latency, and service inversion, and demonstrate that our new servers overcome the latency and blocking problems previously observed. In our earlier work on DeBox (17), we modified the Flash Web server to avoid blocking. We briefly describe those changes to provide the context for our new results with Apache.

Since the blocking has multiple origins, we believe a portable user-level process is preferable to invasive kernel changes. Accordingly, we modify both servers to reduce blocking. Our new contribution in this respect is to identify how Apache can be easily modified to take advantage of the same kinds of changes that helped Flash. Additionally, we focus on latency and service quality evaluation of the resulting servers, in order to understand how the new techniques work.

Our earlier changes to Flash focus on detecting and avoiding blocking, or moving blocking out of the main server process. The open() and stat() calls are moved entirely out of the main process, and the helpers return file descriptors and metadata information to the main process using the sendmsg() system call. Thus, the main process can operate continuously without blocking. Data copying is eliminated by using sendfile() instead of writev(), and the memory-mapping calls that were used in conjunction with writev() are eliminated. Finally, some other changes are made to sendfile() to reduce its memory usage and eliminate disk access. We term the resulting server New-Flash.

Figure 12: Flashpache architecture




Subsections
next up previous
Next: Flashpache Up: Understanding and Addressing Blocking-Induced Previous: Quantifying Service Inversion
Yaoping Ruan
2006-04-18