21-04-2010, 11:57 PM
A Web Service for evaluation of load balancing strategies for distributed web server systems
Number of users accessing the Internet is increasing quite rapidly and it is common to have more than 100 million hits a day for popular web sites. For example, netscape.com website receives more than 120 million hits a day. The number of users is expected to continue increasing at a fast rate and hence any website that is popular, faces the challenge of serving very large number of clients with good performance. Full mirroring of web servers or replication of web sites is one way to deal with increasing number of requests. Many techniques exist for the selection of the nearest web server from the clientâ„¢s point of view. Ideally, selection of best server should be done transparently without the intervention of the user.
Many of the existing schemes do only load-balancing. These schemes assume that the replicated site has all the web servers in one cluster. This is alright for medium sized sites, but beyond a certain amount of traffic, the connectivity to this one cluster becomes a bottleneck. So large web sites have multiple clusters, and it is best to have these clusters geographically distributed. This changes the problem to first select the nearest cluster and then do load balancing within the servers of that cluster. Of course, if all servers in a cluster are heavily loaded then another cluster should have been chosen. So the problem is more complex in such an environment.
Designing such a system involves making decisions about how the best server can be selected for a request such that the user gets a response in minimum time and how this request is directed to that server. In some strategies, a server is selected without taking into account any system state information, e.g. random, round robin etc. Some policies use weighted capacity algorithms to direct more percentage of requests to more capable servers. Some strategies select a server based on the server state and some others take client state information into account. There is always a trade off between the overhead due to collection of system state information and performance gain by use of available state information. If too much state information (of server or clients) is collected, it may result in high overheads for collection of information and performance gain may not be comparable to overheads. The performance of any load balancing approach depends on a host of features like network delays, packet losses, transmission errors, rate of requests, server load etc. It is usually very hard to analytically determine the performance of a policy given some conditions. Simulations also have limitations in that they can only take limited variables into account and with the complexities involved in this case effect of all the variables cannot be analytically determined and simulated. Hence testing for performance by setting up a testbed is a reasonable way to evaluate different strategies.
This testing will in general require a dedicated testbed on which performance studies can be done. Such a testbed should be configurable for different strategies and network characteristics. As such a testbed is likely to be a dedicated set up with a focussed purpose, it will be useful if a web service can be created for evaluating a policy. In this, all parameters will be set in the web service, which will then drive the testbed to obtain the results. Such a service will make a dedicated testbed accessible across the world. Such a service should fulfil a number of requirements. It should be possible to study the impact of different parameters on the performance of various strategies and to compare them. It should be possible to submit new strategies and compare their performance with existing ones or to identify conditions where the policy performs best.
In this project, we develop a web service for evaluating load balancing strategies for distributed web server systems. The web service interacts with a testbed to automate the process of submission of parameters, testing and result generation to allow the user to test and compare load balancing policies through in a highly configurable manner. We have pre-defined some popular strategies which can be evaluated for different parameter settings. The service also allows users to test new policies for load balancing and compare their performance with that of existing ones on a variety of parameters and under various conditions and settings.
System Design and Architecture
The entire system consists of three main components that interact to provide the previously described services.
¢ The Test bed at the back end is a physical set up which can be configured to simulate a variety of network conditions, load conditions, server architectures and load balancing policies.
¢ The web service at the front end is where the interaction with the users takes place and which automates the process from submission of test parameters by the user, configuring the test bed to follow those parameters, running tests and display of results to the users. It includes the web server, application logic, database server and the interface to the testbed.
¢ Also an API has been designed and implemented using which new policies can be submitted for testing on the testbed. It includes standard libraries (API™s) using which a set of interfaces have to be implemented by the user according to the policy he is submitting
Number of users accessing the Internet is increasing quite rapidly and it is common to have more than 100 million hits a day for popular web sites. For example, netscape.com website receives more than 120 million hits a day. The number of users is expected to continue increasing at a fast rate and hence any website that is popular, faces the challenge of serving very large number of clients with good performance. Full mirroring of web servers or replication of web sites is one way to deal with increasing number of requests. Many techniques exist for the selection of the nearest web server from the clientâ„¢s point of view. Ideally, selection of best server should be done transparently without the intervention of the user.
Many of the existing schemes do only load-balancing. These schemes assume that the replicated site has all the web servers in one cluster. This is alright for medium sized sites, but beyond a certain amount of traffic, the connectivity to this one cluster becomes a bottleneck. So large web sites have multiple clusters, and it is best to have these clusters geographically distributed. This changes the problem to first select the nearest cluster and then do load balancing within the servers of that cluster. Of course, if all servers in a cluster are heavily loaded then another cluster should have been chosen. So the problem is more complex in such an environment.
Designing such a system involves making decisions about how the best server can be selected for a request such that the user gets a response in minimum time and how this request is directed to that server. In some strategies, a server is selected without taking into account any system state information, e.g. random, round robin etc. Some policies use weighted capacity algorithms to direct more percentage of requests to more capable servers. Some strategies select a server based on the server state and some others take client state information into account. There is always a trade off between the overhead due to collection of system state information and performance gain by use of available state information. If too much state information (of server or clients) is collected, it may result in high overheads for collection of information and performance gain may not be comparable to overheads. The performance of any load balancing approach depends on a host of features like network delays, packet losses, transmission errors, rate of requests, server load etc. It is usually very hard to analytically determine the performance of a policy given some conditions. Simulations also have limitations in that they can only take limited variables into account and with the complexities involved in this case effect of all the variables cannot be analytically determined and simulated. Hence testing for performance by setting up a testbed is a reasonable way to evaluate different strategies.
This testing will in general require a dedicated testbed on which performance studies can be done. Such a testbed should be configurable for different strategies and network characteristics. As such a testbed is likely to be a dedicated set up with a focussed purpose, it will be useful if a web service can be created for evaluating a policy. In this, all parameters will be set in the web service, which will then drive the testbed to obtain the results. Such a service will make a dedicated testbed accessible across the world. Such a service should fulfil a number of requirements. It should be possible to study the impact of different parameters on the performance of various strategies and to compare them. It should be possible to submit new strategies and compare their performance with existing ones or to identify conditions where the policy performs best.
In this project, we develop a web service for evaluating load balancing strategies for distributed web server systems. The web service interacts with a testbed to automate the process of submission of parameters, testing and result generation to allow the user to test and compare load balancing policies through in a highly configurable manner. We have pre-defined some popular strategies which can be evaluated for different parameter settings. The service also allows users to test new policies for load balancing and compare their performance with that of existing ones on a variety of parameters and under various conditions and settings.
System Design and Architecture
The entire system consists of three main components that interact to provide the previously described services.
¢ The Test bed at the back end is a physical set up which can be configured to simulate a variety of network conditions, load conditions, server architectures and load balancing policies.
¢ The web service at the front end is where the interaction with the users takes place and which automates the process from submission of test parameters by the user, configuring the test bed to follow those parameters, running tests and display of results to the users. It includes the web server, application logic, database server and the interface to the testbed.
¢ Also an API has been designed and implemented using which new policies can be submitted for testing on the testbed. It includes standard libraries (API™s) using which a set of interfaces have to be implemented by the user according to the policy he is submitting