There are numerous load balancing algorithms employed by the Total Uptime Cloud Platform to determine which service to select for the redirection of client requests. Getting to know more about each will help in choosing the best method for your load balancing needs.
When using this method, new connections will be directed to the service with the least amount of connections. This method functions best in environments in which the servers have similar capabilities.
When configured to use round robin, the load balancing virtual server sends a request to the first available service and then rotates that service to the bottom of the list. The next request is sent to the service which was moved to the top of the list, and the cycle continues. This method functions well in most environments, especially in instances where the servers are similar in processing speed and memory.
The least response time algorithm determines which service to send traffic based on two factors: the number of active connections and the average response time. The service with the least active connections and the lowest average response time is chosen to receive the next connection. This method helps distribute the load in a manner in which there are not servers sitting idle.
When the load balancing virtual server is configured to use the URL Hash method a hash value is generated from the HTTP URL present in the request and then forwarded to the selected service. All future connections using an identical URL will be forwarded to the same service. This is helpful in situations where end users have cached data which they need to access, such as a site’s shopping cart. If they are directed to a service without that cached data they can become very frustrated.
By default the load balancer uses the first 80 bytes of the URL for the hash value, or the entire URL if it is less than 80 bytes. You may specify any hash length between 1 and 4096. Longer hash lengths are useful to more evenly balance the load when you utilize longer URLs where only a small number of characters are different.
The Domain Hash method works in much the same way as URL Hash, though instead of hashing the entire URL, only the domain name is hashed. The domain name is taken from either the URL or the host header of the HTTP request, with preference going to the URL if a domain name is found in both. In the case that no domain name is found in the HTTP request, the virtual server defaults to the Round Robin method.
The calculation of the hash value uses the domain name length or the hash length value, whichever is smaller. You may specify a specific hash length between 1 and 4096.
When this method is employed, the load balancing virtual server monitors the amount of traffic to each service, measured in megabits per second, and sends requests to the service utilizing the least bandwidth. Like the Least Connection method, this can help evenly distribute the load, keeping services from sitting idle.
When the load balancing virtual server is configured to use this method, requests are sent to the service which has received the fewest packets within the last 14 seconds.
This method uses the hashed value of the source and destination IP addresses to select which service to send requests. Like the other hashed values, all future requests from a specific pair of addresses will be forwarded to the same service. Please note that this works for both IPv4 and IPv6 traffic, and that the hash value will be the same regardless of the order of the source and destination IPs.
This method selects the service using the least response time based upon the monitors configured for each server. In order for this method to work all servers must have monitors bound to them with LRTM enabled on each.
This method uses the hash value of the source IP address and source port to select which service to send requests. This works for both IPv4 and IPv6 addresses.
This method compares the IP address of the user making the request with the IP address of the the devices in the load balancer to determine which one is the closest. This is done on a country basis. For example, if you have two servers in the load balancer, one in Ireland and the other in New York, a user from the United States, Canada, etc. would be routed to the New York server (assuming it was online and available) and any user from any European country would be routed to the Ireland server (assuming it was online and available). If either the New York or Ireland server goes down, then the next closest server would be used.
Geographic Proximity cannot be more granular than per-country. This is because IP databases are not that accurate. To compensate for this, we recommend using the GEO Weighting feature. This will allow you to weight North America in three sections, East, Central and West, and Europe into UK and EU. We will soon expand this functionality further. The combination of Geographic Proximity and GEO Weighting is an extremely powerful tool for routing users to the device closest to them for the best performance and response time.