How to calculate the maximum amount of load on a Web server

The dynamic feedback load balancing algorithm takes into account the real-time load and the response of the server, adjusts the ratio of processing requests between servers, to avoid some servers being overloaded and still receive a large number of requests, thus increasing the throughput rate of the whole system. Figure 1 shows the working environment of the algorithm, running the monitor daemon process on the load scheduler, and monitor daemon monitors and collects the load information for each server. The Monitor daemon can calculate a composite load value based on multiple load information. Monito R Daemon calculates a new set of weights for each server's combined load and current weights, and if the difference between the new weight and the current weight is greater than the set threshold, Monitor daemon sets the server's weight to the Ipvs dispatch in the kernel, In the kernel, the connection scheduling is generally based on the weighted scheduling algorithm or the weighted minimum connection scheduling algorithm.

Figure 1: The working environment of dynamic feedback load balancing algorithm

Connection scheduling

When a client accesses network access over a TCP connection, the time required for the service and the computational resources to be consumed vary widely, depending on a number of factors. For example, it relies on the type of service requested, current network bandwidth, and current server resource utilization. Some load-heavy requests require computationally intensive queries, database access, long response data streams, and lighter-load requests that often require only reading an HTML page or making simple calculations.

The diversity of request processing times can cause the server to exploit the skew (Skew), the load imbalance between servers. For example, there is a Web page with a, B, C, and D files, where D is a large image file, and the browser needs to establish four connections to fetch the files. When multiple users access the page at the same time through a browser, the most extreme case is that all D files are sent to the same server. So it's possible that some servers are overloaded and other servers are basically idle. At the same time, some servers are already busy, have a long queue of requests, and continue to receive new requests. Conversely, this will cause customers to wait for a long time and feel that the system is poor quality of service.

Simple connection Scheduling

Simple connection scheduling may cause server tilt to occur. In the example above, if a round robin algorithm is used, and there are exactly four servers in the cluster, a server must always receive a request for D files. This scheduling strategy leads to low utilization of resources throughout the system, as some resources are exhausted, causing customers to wait for a long time while others are idle.

Characteristics of actual TCP/IP traffic

The literature shows that the network traffic is a wave-like occurrence, after a long period of small flow, there will be a large flow of access, and then a small flow, so as the wave occurs periodically. The literature reveals that network traffic has self-similar characteristics on WAN and LAN, and self-similarity exists in Web Access stream. This requires a dynamic feedback mechanism, using the state of the server group to deal with the self-similarity of the access stream.

Dynamic Feedback load Balancing mechanism

The characteristics of TCP/IP traffic Generally speaking, there are many short transactions and a number of long transactions, while the workload of long transactions in the total amount of work accounted for a higher proportion. So, we're going to design a load-balancing algorithm to avoid long service requests being allocated to some machines, but to split the distribution of burrs (Burst) into relatively uniform distributions as much as possible.

We propose a dynamic feedback load balancing mechanism to control the allocation of new connections, thus controlling the load on each server. For example, a weighted round robin (weighted round-robin scheduling) algorithm is used in the kernel of the IPVS Scheduler to dispatch new request connections, and monitor Daemon is run in the user space of the load scheduler. Monitor daemon regularly monitors and collects the load information of each server, and calculates a composite load value based on multiple load information. Monitor Daemon calculates a new set of weights for each server's combined load value and current weight. When a composite load value indicates that the server is busier, the newly calculated weight is smaller than its current weight, so that the number of requests that are assigned to the server is less. When a composite load value indicates that the server is at low utilization, the newly calculated weight is larger than its current weight to increase the number of requests newly allocated to that server. If the difference between the new weight and the current weight is greater than the set threshold, Monitor daemon sets the server's weight to the Ipvs schedule in the kernel. After a certain time interval (such as 2 seconds), Monitor daemon The situation of each server, and adjust the server's weight, so periodically. It can be said that this is a negative feedback mechanism, so that the server to maintain a good utilization.

In the weighted round robin algorithm, when the server has a zero weight, the established connection continues to receive the server's service, and the new connection is not assigned to the server. The system administrator can set the weight of a server to zero, make the server quiet, and when an existing connection is over, he can cut out the server and maintain it. Maintenance work on the system are essential, such as hardware upgrades and software updates, 0 weight to make the server quiet function is very important. Therefore, in the dynamic feedback load balancing mechanism we want to ensure that the function, when the server's weight is zero, we do not adjust the weight of the server.