Taking its name from a principle in other fields that gives each person an equal share in turn, round robin load balancing is one of the simplest scheduling algorithms for processes in operating systems. It assigns time slices to each process in equal portions and in order, handling all processes without priority. Round robin scheduling is both simple and easy to implement.
Round robin scheduling can be applied to other scheduling problems, such as data packet scheduling in computer networks.
Persistent round robin is similar to round robin load balancing, except each visiting client remains with the same server until they log off or the inactivity timer expires.
Weighted round robin takes into account the server capacity. More powerful servers have a higher “weight,” while older or less powerful servers have lower “weight.” WebMux will load balance based on the weight of each server. Please use minimum normalized weight numbers. (Instead of 99 and 100 for two servers, use weights 1 and 1, as there is hardly any difference. Instead of using 80 and 60 for two servers, use weights 4 and 3, or 2 and 1.) WebMux sends the same number of requests to a server as its weight before requesting another server.
Persistent Weighted Round Robin
Since 1998, WebMux supports a least connections method that distributing visitors to a site to multiple servers based on the number of connections already on a server. WebMux distributes new connections to the server has least connections based on a few factors.
WebMux supports a least connections method that distributes visitors on a site to multiple servers based on the number of connections already in use on a server. WebMux distributes new connections to the server that has the least connections, amongst other factors.
Persistent Least Connections
Persistent least connections keep the client with the same server, until they sign off or the inactivity timer expires. Note that “persistent” works against the least connection logic, so the result may not be ideal.
Weighted Least Connections
WebMux allows the user to set a weight to each server, so that new and old servers can serve the same site/farm together. Minimum normalized numbers are preferred for weights. WebMux will move from one server to another based on weight, so smaller weights are preferred.
Persistent Weighted Least Connections
Although both persistent and weight algorithms work against the least connection algorithm, WebMux still tries to send connects to servers based on all three factors. The net result may not be what the user wants.
Weighted Fast Response
WebMux distributes the load to servers based on the weight and the server response time. This method sounds good, but to get the best response based on server response you also have to consider the server’s resources. We recommend using the custom health check method to best load balance the traffic.
Persistent Weighted Fast Response
We do not recommend using persistent weighted fast response load balancing. Consider using the customer health check method.
Layer 2/3/4/5/7 Load Balancing
WebMux can load balance visitors in different network layers. For network definitions, please visit Network Layers. Remember that WebMux obeys the ISO/OSI layer definitions
Layer 7 URI Load Directing
WebMux can manage traffic based on Layer 7 rules. One of the rules bases load directing on the URI. URI is a portion of the complete URL. The match pattern can be anchored from the start of the URL, or not anchored to match anywhere in the URL. When more than one servers have the same URI, the incoming requests will use round robin to load balance between the servers.
Layer 7 URI Load Directing with Host Name MIME Header Matching and Cookies
Cookie and URL are part of host MIME header. For details of the MIME header, please read the HTTP protocol RFC 2616. WebMux can match part of the MIME header to achieve the traffic management tasks. Newer algorithms are being added to the WebMux supporting different load balancing needs.
1) The custom health check method allows users to write their own cgi code on their servers to detect all situations to give the best feed back to the WebMux so it can increment, decrement, or stop sending any load at all to the server.