The Internet Encyclopedia (Volume 3)

P1: IML/FFX P2: IML/FFX QC: IML/FFX T1: IML

Web ̇QOS WL040/Bidgoli-Vol III-Ch-58 July 16, 2003 9:36 Char Count= 0

PERFORMANCEGUARANTEES INWEBSERVERS 713

use server-side caches (also known as reverse proxies) to

reduce the load on the server. The caching infrastructure

significantly affects the user-perceived performance of the

Web. Arlitt, Friedrich, and Jin (1999) compare the effects

of different replacement plocies on cache performance.

Recent research efforts address developing caches that

provide some form of performance differentiation or QoS

guarantees. A proxy cache, for example, can offer pref-

erential treatment to content requested by a certain sub-

set of clients or content belonging to a certain subset of

providers. This mechanism will be described in later sec-

tions.

PERFORMANCE GUARANTEES IN

WEB SERVERS

In this section, we describe performance guarantee mech-

anisms for Web server end-systems. As a running applica-

tion example, consider a Web server farm that hosts multi-

ple Web sites on behalf of different content providers. Web

hosting is a growing business in which major investments

are made by companies such as Intel, IBM, and Hewlett

Packard. We discuss the type of performance guarantees

required, the parties to whom the guarantees are made,

and the mechanisms used to enforce these guarantees.

The server farm example provides a context for describ-

ing the general classes of server performance challenges

and helps illustrate solutions needed when resources are

shared among multiple parties with different QoS require-

ments.

A Web hosting service interacts with at least three dif-

ferent parties: (i) end users who access the hosted content,

(ii) content providers who own the Web sites exported for

hosting, and (iii) network providers who provide Internet

connectivity to the Web hosting farm. End users are typi-

cally interested in a fast response time; content providers

care more about throughput, which translates into total

capacity dedicated to their Web sites; and network

providers care primarily about network bandwidth con-

sumed by the hosting installation. In general, the mech-

anisms to provide these guarantees lie either on servers

(i.e., on the end system) or inside the network. Below, we

investigate QoS mechanisms on the end system. Network-

level mechanisms are described elsewhere in this encyclo-

pedia.

Performance Isolation

The most basic guarantee needed among multiple traffic

classes is that of performance isolation. Informally, the

guarantee states that the performance seen by any par-

ticular class of clients should be independent of the load

imposed by any other class. For example, consider a Web

server that hosts two Web sites, A and B, where B is a very

popular site. Unless proper action is taken, B may over-

load the entire server, preventing the clients of A from ac-

cessing the server. Performance isolation imposes limits

that prevent a site such as B from monopolizing the server.

There are several different ways performance isolation

may be implemented. They typically rely on some form of

resource allocation and admission control. In the follow-

ing subsections, we discuss some of the most important

mechanisms for performance isolation in the operating

system, middleware, and application layer.

Operating Systems Solutions

The core mechanism for performance isolation is re-

source reservation. Each Web site must be allocated its

own resource quota on the Web server. Requests for that

Web site are allowed to consume only those computing

resources that are within the site’s quota. Excess load on

one site should not be allowed to divert resources dedi-

cated to other sites. Traditionally, resource allocation and

management is the responsibility of operating systems.

Hence, the most fundamental solutions to performance

isolation are operating system solutions.

Generally speaking, in a shared computing system,

such as a server farm shared by multiple cohosted Web

sites, common resources can be categorized into two dif-

ferent types; those that are shared in time and those that

are shared in space. Space-shared resources include, for

example, memory and disk space. Different processes may

own different subsets of the resource concurrently and

be denied access to resources owned by others. Space-

sharing implies that the resource can be partitioned. Some

resources, however, are indivisible. The prime example is

the CPU. Indivisible resources can only be time-shared. In

other words, they can only be allocated in their entirety

to one process at a time. Clients are queued up on the

time-shared resource. The queuing order and duration of

resource access allowed by each client decide how the re-

source is shared.

Traditional operating systems such as UNIX imple-

ment a time-sharing scheduling policy, which allocates

the processor one quantum at a time in a round-robin

fashion among the waiting processes. This policy is inade-

quate for performance isolation in that it does not prevent

any one class of clients from monopolizing the CPU. Con-

sider our server farm example, where it is desired to isolate

requests for different sites cohosted on the same platform.

The CPU capacity available to one site under the UNIX

time-sharing scheduling policy is roughly proportional to

the number of processes serving that site at a given time.

This number is in turn proportional to the client request

rate. An overloaded Web site with a large request rate gen-

erates a large number of processes to serve these requests.

It can therefore monopolize the CPU.

To ensure performance isolation, many researchers

have addressed the problem of reservation of time-shared

resources. The first effort on this subject came from

the Real-Time Mach project at Carnegie Mellon Univer-

sity and is calledprocessor capacity reserves. The idea of

processor capacity reserves is to implement separate ac-

counting entities (the reserves), which keep track of the

processing budgets allocated to abstract CPU activities.

For example, a programmer can associate a budget with

each separate Web site on the hosting server. The bud-

get specifies the percentage of time that the CPU is al-

lowed to spend on the corresponding site, e.g., 4 ms every

30 ms. The budget is replenished periodically. To enforce

performance isolation, when a Web server reads a request,

the request is classified and the corresponding budget is

charged for the time it takes to serve the request. If the

reserve is exhausted before the end of the period, the