Different Models of Web Servers

Like many other servers, web servers have certain performance requirements that affect how the server is implemented. Several possibilities are available for the architectural model that the server is implemented with. One of the major issues is how the server handles concurrency. Web servers are required to handle many clients simultaneously, sometimes up to tens of thousands of clients. In the previous example, the server deals with only one client at a time. For example, if the file that the client requests is not in the server's file cache, the server blocks waiting for the file to be loaded from disk. During this time, the server could be handling other requests that may be less expensive to serve, but the previous example instead waits, wasting cycles. In addition, because the previous example uses a single process, if the server is an SMP, other processors are completely underutilized. The typical approach to dealing with this problem is through some form of concurrency mechanism; we describe several approaches in this section.

The most common form of concurrency is using processes. The most popular web server, Apache, was originally implemented using processes. Each process has a separate address space and is fully protected and isolated from other processes through a virtual machine abstraction. By assigning each request to a separate process, one process can make forward progress while another is blocked on another activity (such as waiting for a client or disk). In addition, on an SMP, multiple processes can run in parallel. The disadvantage of processes is that they are relatively expensive abstractions to use, requiring resources such as memory to be allocated to them. If a server has thousands of clients, it may have thousands of processes, which can tax a system's resources. Typically, any system is limited in the number of processes it can have active.

The next most common approach is using threads. Apache 2.0 provides the option of using threads rather than processes. Threads are similar to processes but are lighter-weightnamely, they require fewer system resources. Threads typically share address spaces but have separate program counters and stacks. Threads are cheaper than processes but trade protection for speed. In addition, systems can run low on resources even using threads, given a large enough number of clients.

Many research web servers, such as the Flash web server from Rice University (not to be confused with MacroMedia's Flash browser plug-in), use something called the event-driven model. In this model, a single process is used, without threads, and connections are managed using a multiplexing system call such as select() or poll(). The server queries the readiness of all connections using the system call and determines which connections require service (and, conversely, which are idle). The server then reads requests or writes responses as appropriate for that particular connection. The advantage of the event-driven model is that it is typically faster than process- or thread-based servers, because it maximizes locality and has many performance optimizations not available to these other models. The disadvantage is that it is more difficult to program, because the developer must explicitly manage state for many requests, each of which can be in a different stage of progress. In addition, operating system support for interacting with the disk in this model (namely, asynchronously) has been historically absent in Linux. However, with the introduction of asynchronous I/O in Linux 2.6, this limitation is being remedied.

The final architectural model we consider here is the in-kernel model. Examples include Red Hat's Tux server and IBM's AFPA server. In this approach, the entire web server is run as a set of kernel threads, rather than in user space. The advantages of this approach are that performance is maximized (because sharing is easy), data copies are avoided, and no expensive user-kernel crossings are incurred. The disadvantages are that kernel programming is more difficult, less portable, and more dangerous than user-space programming. For example, if the server has a programming error and crashes, an in-kernel server could take down the whole machine with it.