by
Sukanya Suranauwarat
Department of Computer Science, School of Applied Statistics, National Institute of Development Administration, Bangkok 10240, Thailand.
In this paper, we describe and evaluate our load distribution policy. This policy makes placement decisions for processes of each service in such a way that the estimated response time is optimized while the estimated throughput is in the range that the user desires. Our target service is a transaction service consisting of multiple processes that communicate with each other. Our target system is a distributed system consisting of workstations connected by a local area network. The outstanding feature of our policy is that it takes account of pre-loaded service, ones for which process allocation has already been determined before the newly arrived service. In other words, our policy tries to keep the performance of the pre-loaded services at a desirable level while the newly arrived service processes are loaded and run. We measured the response time and the throughput when the process allocation is
determined using our policy, and we compared them with those our policy estimates. The results show that our policy provides an appropriate process allocation, and that calculated results agree well with the measured ones.
Introduction
The advent of inexpensive microcomputers, powerful workstations, and wide-bandwidth networks caused distributed systems to become increasingly popular. One of the most important features of such systems is the possibility of achieving high performance by means of load distribution. Load distribution attempts to improve the performance of application programs by distributing their processes (i.e., the load) among the computers in a network.
The effect of load distribution depends on the load distribution policy. So far, many load distribution
policies (e.g., [1]-[9],[11]) have been proposed, most of which focused on the load on a single resource in a computer especially a CPU resource, even though processes usually require various types of resources for their execution. In this case, it may not be meaningful to assign an incoming I/O-bound process to a computer that the CPU is lightly loaded while the I/O resources it uses are not. In other words, an incoming I/O-bound process will not necessarily run faster on a more lightly loaded CPU, and it might even run slower if the I/O resources it uses are congested. Moreover, the previous studies [1]-[8] have demonstrated the performance benefit of their policies using simple workload and system models. For example, the workload consists of only CPU-bound processes and all the computers in a network are identical, which makes the comparison of the load among the computers easier since the information about the specifications of the computers and the network is not a concern, and thus the processes are simply assigned to the computers that have the least number of processes. Another example, only application programs that generate a single process are considered, thus the relation and interaction between processes of the same program is not a concern.
Therefore, the policies mentioned above are not suitable for the programs that are widely used in business and require have high performance like transaction processing programs, because the execution of each transaction processing program usually causes the creation and the execution of multiple cooperative processes which require various types of resources and interprocess communication (IPC) in order to carry out each transaction. Hence, we propose a load distribution policy for transaction processing programs on distributed systems consisting of heterogeneous workstations connected by a local area network (LAN). Unlike previous policies, our policy takes
into account the information about the specifications of the computers and the network and the information about the execution behavior of the programs, i.e., the resource consumption behavior of each process and its interaction with other processes (i.e., IPC), in making placement decisions for each process. To be more specific, our policy estimates the response time and the throughput of any transaction service using the information about the specifications of the computers and the network and the information about the execution behavior of the programs, and distributes each process of the service in such a way that the estimated response time is optimized while the estimated throughput is in the range that users desire (i.e., our policy allows users to set the lower and the upper limits of the throughput).
However, when some services have already been executed on the distributed system (pre-loaded services), it becomes harder to estimate the response time, because the correlation between the newly arrived service (new service) and the pre-loaded services has to be considered. For example, consider a situation in which a process of a new service is assigned to a computer. Beginning an execution of a new process on a computer requires reallocation of the computing resource (such as the CPU or memory) for each process running on the computer. This will affect the time it takes to complete one transaction in each process, and thus affecting the processes of the same services running on the other computers, because the processes use IPC. Consequently, just one new process affects all the other processes in the system. The effect spreads through the system until all the processes on the system are stable. This makes it difficult to take account of the pre-loaded services in the calculation. We name this problem the process chain problem. As a solution, we introduce the bottleneck coefficient into our load distribution policy.
The rest of this paper is organized as follows. Section 2 briefly discusses the related work. Section 3 describes the model of our system. Section 4 describes the method of estimating response time of a transaction service. Section 5 describes our load distribution policy. Section 6 describes our experiments and explains the results we obtained. Section 7 offers our conclusions and future work.
Download Full Text at http://www.bloggang.com/viewdiary.php?id=inthedark&month=06-2007&date=30&group=14&gblog=15