Stingray can load balance servers in a few different ways. Looking at a Pool's Load Balancing configuration page shows the different options:
They're all pretty straightforward except for Perceptive; how does that one work? Perceptive can be thought of as Least Connections skewed to favor the servers with the Fastest Response Time. Perceptive factors in both connection counts and response times into the load balancing decision to ensure that traffic is distributed evenly amongst the servers in a farm. It is best understood in the context of a few examples:
A great scenario in which to use Perceptive is when your server farm is heterogeneous, where some servers are more powerful than others. The challenge is to ensure that the more powerful servers get a greater share of the traffic, but that the weaker servers are not starved.
Perceptive will begin by distributing traffic based on connection counts, like Least Connections. This ensures that the weaker servers are getting traffic and not sitting idle. As traffic increases the powerful servers will naturally be able to handle it better, leading to a disparity in response times. This will trigger Perceptive to begin favoring those more powerful servers, as they are responding quicker, by giving them a greater share of the traffic.
Another great scenario in which to use Perceptive is when your workload is heteregeneous, where some requests generate a lot more load on your servers than others. As in the Heterogeneous Server Farm case, Perceptive will begin by distributing traffic like Least Connections. When the workload becomes more heterogeneous, some servers will get bogged down with the more CPU intensive requests and begin to respond slower. This will trigger Perceptive to send traffic away from those servers, to the other servers that are not bogged down and responding quicker.
The perceptive algorithm introduces traffic to a new server (or a server that has returned from a failed state) gently. When a new server is added to a pool, the algorithm tries it with a single request, and if it receives a reply, gradually increases the number of requests it sends the new server until it is receiving the same proportion of the load as other equivalent nodes in the pool. The algorithm used to ramp up the load is adaptive, so it isn't possible to make statements of the sort "the load will be increased from 0 to 100% of its fair share over 2 minutes"; the rate at which the load is increased is dependent on the responsiveness of the server. So, for example, a new web server serving a small quantity of static content will very quickly be ramped up to full speed, whereas a Java application server that compiles JSPs the first time they are used (and so is slow to respond to begin with) will be ramped up more slowly.
The Perceptive load balancing algorithm factors in both connection counts along with response times into a two step load balancing decision. When there is little disparity in response times, traffic will be distributed like Least Connections. When there is a larger disparity in response times, Perceptive will factor this in and favor the servers that are responding quicker, like Fastest Response Time. Perceptive is great for handling heterogeneity in both the server farm and the workload, ensuring effecient load balancing across your server farm in either case.
For a more detailed discussion of the load balancing capabilities of Stingray, check out Feature Brief: Load Balancing in Stingray Traffic Manager, and take a look at the video introduction: Video: Introduction to Stingray Load Balancing