Skip past navigation linksSecure Global Desktop 4.40 Administration Guide > SGD Servers, Arrays, and Load Balancing > Tuning Application Load Balancing

Tuning Application Load Balancing

Administrators can tune application load balancing by editing application load balancing properties. These properties affect how the load balancing service used for Advanced Load Management operates, and how SGD calculates the application server load.

This page describes how you can tune load balancing and assumes you understand how SGD load balancing works. With the exception of tuning an application server's relative power, the following tuning only applies if you are using the Least CPU Usage and Most Free Memory methods of application load balancing (Advanced Load Management):

The Application Server's Relative Power

The weighting property allows you to factor in the relative power of the application servers to the decision SGD takes as to where to launch an application. This is discussed in Configuring load balancing.

Load Balancing Ports

The primary SGD server in the array contacts the load balancing service on an application server on TCP port 3579. This is controlled by the listeningport property.

The load balancing service sends updates to the primary SGD server on UDP port 3579. This is controlled by the probe.listeningport property.

These ports are registered with the Internet Assigned Numbers Authority (IANA) and are reserved for use only by SGD. Only change these properties if Support asks you to. You must open these ports if you have a firewall between the primary SGD server and the application servers.

SGD Server Requests Updates From an Application Server

The connectretries property is the number of times the primary SGD server tries to connect to an application server to request load updates. The interval between each attempt is controlled by the shorttimeout property. If the attempts to connect fail, the SGD server waits for the period of time controlled by the longtimeout property before trying again.

For example, using the defaults for these properties, the SGD server makes 5 attempts (connectretries) to contact the application server at 20 second intervals (shorttimeout). If all 5 fail, SGD waits 600 seconds (longtimeout) before making 5 more attempts at 20 second intervals.

You might want to change the timeout properties, for example, if your application server takes a long time to reboot.

The scaninterval property controls the period of time between scans of the SGD server's list of load-balanced application servers. The scan checks for the application servers that need to be contacted to request a load update (connectretries).

The sockettimeout property controls how long it is before an SGD server gets an error by trying to contact the load balancing service when there is no data available.

Frequency of the Load Calculation

The probe.samplerate and probe.windowsize properties control how often the load balancing service measures the application server's average load.

For example, the probe.samplerate is 10 seconds and the probe.windowsize is 5. After 50 seconds (5 x 10), the 5 measurements needed to calculate the average have been taken. After a further 10 seconds, the load balancing service takes a new measurement, discards the oldest measurement and then calculates a new average load.

You can increase and decrease the frequency of the calculation depending on how often you expect the application server load to change. For example, if users start applications at the start of the day and then close them at the end of the day, you might want to decrease the frequency of the load calculation. However, if users repeatedly start and stop applications, you might want to increase the frequency of the load calculation.

Frequency of Updates to the Primary SGD Server

The replyfrequency property controls the interval at which the load balancing service send updates to the primary SGD server.

The percentagechange property controls the minimum percentage change in CPU/memory use that must be reported to the primary SGD server. The load balancing service sends these updates as soon as the percentage change occurs. For example if an application server is running at 30% CPU load and the percentchange value is 10, an update occurs when the load is either 20% or 40%. The load balancing service takes into account sudden 'spikes' of activity and also makes adjustments when, for example a server reaches 81% CPU load and the percentagechange value is 20%.

The replyfrequency updates are sent even if the load does not change and even if there has been a percentagechange update. The basis for the percentagechange calculation is reset every time there is a replyfrequency update.

If there is no update from an application server for updatelimit x replyfrequency seconds, SGD considers the application server to be 'out of contact'. This means the application server is marked as unavailable to launch applications until the SGD server can re-establish contact with it.

Reliability of CPU and Memory Data

SGD considers the CPU and memory data it receives to be too unreliable if there has been no update from the application server for updatelimit x replyfrequency seconds.

Note The load balancing service sends updates even if the load does not change.

If the data is unreliable, the data is ignored when making the decision on where to launch an application. The net effect of this is to make the application server the last in the queue so that it can only be used to launch applications if no other server is available or suitable.

Frequency of Updates to Array Members

The primary SGD server sends CPU and memory load updates to the other members of the array every maxmissedsamples x replyfrequency/2 seconds. This update takes place even if the load does not change.

If a secondary SGD server misses an update, it considers the load data it has to be unreliable and reverts to the Fewest application sessions method of load balancing. It uses this method until it receives a new update.

Related Topics