Preventing overload

When you configure a NetScaler to use a metric-based load balancing method such as Least Connections, Least Response Time, Least Bandwidth, Least Packets, or Custom Load, the load balancing method will initially start out as Round Robin for what is called a slow start period.

NetScaler appliances use the configured load balancing method to determine the appropriate service for forwarding an incoming request. Load balancing environments are dynamic, however, and the NetScaler needs to manage the events that may overload the server. For example, when you configure the Least Connections load balancing method, the NetScaler selects the service that has the least number of connections. If a new server is added to the server farm, the NetScaler selects the new server with the least number of connections, and, therefore, may overload the new server.

To avoid overloading servers, the NetScaler performs slow start. During the slow start phase, the NetScaler distributes requests by using Round Robin, regardless of the metric-based load balancing method configured on the virtual server. However, the weight assigned on the services is used by Round Robin. After the number of incoming requests or connections per second exceeds a given threshold, the NetScaler stops slow start and operates using the configured load balancing method.

Slow start occurs when:

• You configure a new metric-based load balancing method.
• You bind a service to the virtual server.
• The state of the server changes from DOWN to UP.

To compute slow start, the number of services bound to the virtual server is multiplied by 100. For a new virtual server with the load balancing method determined by dynamic traffic parameters, slow start allows time to collect a valid data sample before the correct method is applied.

Note: When slow start is in operation, the output for the show lb vserver <vserver name> command will specify the current method as Round Robin.

Get the most powerful Load Balancer here.

It’s powerful!