The free encyclopedia Wikipedia defines Round-Robin scheduling as "one of the simplest scheduling algorithms for processes in an operating system, which 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, and starvation-free. Round-robin scheduling can also be applied to other scheduling problems, such as data packet scheduling in computer networks."
More specifically, in Load Balancing, if there are N servers in the farm, then successive users logon to the servers in the following, simple way:
1, 2, 3, .....N,1,2,3...N,1,2,3...N etc., all with the same priority and without regard to any other variable.
Round-Robin scheduling is the preferred Load Balancing method among most OM Web Viewer customers. Most write a software algorithm in one of their routers. Some implement their load balancing using a Cisco ACE. For more on Cisco:
Another option would be to use Microsoft load balancing software. There's a good article about Microsoft NLB (Network Load Balancer) and Load balancing:
At what point or under what conditions does it become apparent that you need another DRAS and/or OM Web Server? When should you load balance? The answer is purely subjective, but most customers don't like to see a system running consistently over 50% utilized. When this occurs, it's time to add another server in the server farm.
What does load balancing OM Web Viewer servers look like? Load balancing efforts are due to limiting resources. These recourses can affect CPU and/or network traffic. Below depicts a typical load balancing topology. Assuming there is one Report Repository, several DRAS tasks can communicate to it in order to balance the CPU load of a particular instance of DRAS. On the "Distributed" side, OM Web Viewer users actually are given the URL of the Load Balancer. The Load Balancer has the algorithm to choose with which Web Viewer to communicate. This algorithm can be a simple "round-robin" one which sends users to the next Web Viewer server in succession. Or it can perform an analysis of the each server and send it to the one with the lowest load. Load is defined by the customer. One of the most important things to note that once a user is initially logged on to a particular Web Viewer server, all subsequent requests must go to that server until the user logoffs from the Web Viewer. This has been termed "persistence" or "using the sticky bit."