Bloggang.com : Darksingha : Improving a WWW Server’s Response Time Using Its ExecutionBehavior Information in ResourceScheduling

Improving a WWW Server’s Response Time Using Its ExecutionBehavior Information in ResourceScheduling

Improving a //www.Server’s Response Time Using Its Execution Behavior Information in Resource Scheduling

Sukanya Suranauwarat
Department of Computer Science, School of Applied Statistics, National Institute of Development Administration, Bangkok 10240, Thailand

With the phenomenal, continual growth in the number of the //www.(World Wide Web) users has come an increase in the number of simultaneous requests a server must handle. As a result, users experience slower response time during periods of high demand. In other words, it takes a longer time for the first data to display on browsers, the text data stored in an HTML (HyperText Markup Language) file, to start displaying when servers are accessed by many requests simultaneously. This situation could be one in which it is most desirable to improve the response time and this can be achieved by scheduling resources more efficiently in operating systems. We have proposed a
resource scheduling policy for improving response time of a //www.server. This policy gives preferential use of the resources such as a CPU resource (or I/O devices) to any process that is predicted based on its execution behavior information to be a server process handling an HTML file request. It does this by moving that process (or its I/O request) to the head of the waiting queue where processes (or their I/O requests) are waiting for the desired resources to become available. In this paper, we present the experimental evaluation of our resource scheduling policy when applied to the allocation of a CPU resource and a disk drive.

Introduction
Over the past several years, the //www.(World Wide Web) has experienced a phenomenal growth in the number of users, and has become the most popular Internet application. It has succeeded because it gives users quick and easy access to a tremendous variety of information in remote locations. With this ongoing growth has come an increasing demand on //www.servers, which results in an increase in the number of simultaneous requests that servers must handle. As a result, users experience slower response times on the //www.sites during periods of high demand. In other words, it takes a longer time for the first data to display on browsers, the text data stored in an HTML (HyperText Markup Language) file, to start displaying when the servers are accessed by many requests simultaneously. This can cause users to get frustrated or give up waiting or even stop accessing those sites any more. Therefore, in such a situation, a server’s response time has become a critical issue for improving the quality of service on the //www.

A way to achieve the goal of improving a server’s response time is to improve operating systems support for servers, especially in the area of resources allocation in which traditional operating systems still perform poorly. This is because most traditional operating systems control the allocation of the resources among processes using a fixed scheduling policy, in which the utilization of a computer system (e.g., a real-time or a time-sharing system) is a major concern rather than contents or behavior of processes.

For example, in a UNIX time-sharing system, several processes of the same priority may be ready to
run if they could use the CPU if it were available. Since only one process can run at a time, the rest have to wait in the queue until the CPU is free and rescheduled on a round-robin basis. However, in the case of //www.servers, server processes handling HTML file requests are more important than those handling other types of file request, even though they all have the same priority. In addition, several processes may be generating I/O requests. If processes make I/O requests faster than they can be serviced, waiting queues buildup for each I/O device. In the case of a disk drive, traditional operating systems normally enter I/O requests into the queue in such a way that the requests will be serviced with minimum mechanical motion[1],[2], since it is likely to improve the overall performance, however, possibly at the expense of individual requests. In the case of //www.servers, the individual requests, especially the HTML file requests, are important. Therefore, with traditional operating systems, when
the number of server processes needed to handle the simultaneous requests increases, if a server process handling an HTML file request or its I/O request is put at the end of the queue, then it takes a longer time for the text data to show up on browsers, which results in users experiencing slower response times.

Therefore, we proposed a process’ behavior-based resource scheduling policy for improving the response time of a //www.server[3]. This policy gives preferential use of the resources such as a CPU resource (or I/O devices) to any process that is predicted based on its execution behavior information to be a server process handling an HTML file request, by moving it (or its I/O requests) to the head of the waiting queue. This allows each user to get an HTML file faster during periods of high demand, while other types of files (e.g., an Image file), which are embedded in the HTML file by reference, are coming in. In other words, this allows each user to view text and general layout of a //www.page in a timely manner during periods of high demand while other types of data such as an image are coming in, and also to allow the user to stop loading if the page is not sufficiently interesting to warrant waiting.

In this paper, we present the experimental evaluation of our resource scheduling policy when applied to
the allocation of a CPU resource and a disk drive.

The remainder of this paper is organized as follows. Section 2 provides background information on the
//www. Section 3 is a brief overview of our scheduling policy and its aspects of implementation. Section 4 describes our experiments and explains the results we obtained. Section 5 discusses related work. Section 6 offers our conclusion and future work.

Download Full Text

Create Date : 30 มิถุนายน 2550

Last Update : 30 มิถุนายน 2550 12:43:42 น.

0 comments

Counter : 848 Pageviews.