SAS/IntrNet 9.2: Application Dispatcher

Enhancing Performance

As more users access your applications, you might need to fine-tune the performance of your Application Dispatcher setup. You can improve performance by

Using Multiple Servers (Random Load Balancing)

In a socket service definition in the Application Broker configuration file you can supply multiple names of the physical machines on which Application Servers are installed or multiple TCP/IP port numbers that represent many server processes on a single machine. The following example shows multiple servers and ports:

   server machine_a  machine_b  machine_c  machine_d
   port 5000-5002
   server machine_e
   port 5001 5003

This example provides 14 different Application Servers:

3 servers (5000,5001,5002) on machine_a
3 servers (5000,5001,5002) on machine_b
3 servers (5000,5001,5002) on machine_c
3 servers (5000,5001,5002) on machine_d
2 servers (5001,5003) on machine_e

For the Application Broker to access these Application Servers, they must be running. If one or more of the servers is not running, the Application Broker tries to access another one. If you need a diagnostic tool, you can set a _DEBUG value to trace the connection attempts. Notice that you can specify a range of ports, for example, 5000-5002. You can also specify any number of single ports or port ranges on one line.

When a Web browser request is made, the Application Broker uses one of two methods for selecting a server out of the specified service:

If a Load Manager is defined in the configuration file, the Application Broker attempts to ask the Load Manager for an available server in the list that is defined for the service.
If the Load Manager is unavailable or undefined, the Application Broker randomly chooses a server from the list.

Using the Load Manager (Intelligent Load Balancing)

The Load Manager balances requests from Application Brokers for Application Server processing. Each time an Application Broker is activated, it sends a list of Application Servers that are associated with the service to the Load Manager. The Load Manager checks an in-memory list of server states to determine whether any servers are idle. The first server found idle with the least number of outstanding sessions is returned to the Application Broker and marked as in use. If no servers are idle, the request is queued by the Load Manager until a server is free. If the Application Servers are configured with multiple programs enabled, the request is sent to a server that is not handling the maximum number of programs.

Each Application Server contacts the Load Manager to record its state. As a job is received, the server sends a message to the Load Manager indicating that the server is busy. When the job has been completed, an idle state message is sent. In this manner, the Load Manager can maintain which servers are available for Application Broker requests. The Load Manager also periodically checks server sockets to try to determine whether each server is still functioning. The Load Manager log can be used to track the state changes and job allocation for the Application Servers.

Increasing Timeout

The ServiceTimeout directive specifies the number of seconds that the Application Broker should wait for a response from the Application Server. The default value is 60 seconds. This can be lengthened depending upon your needs. When the specified time elapses, the Application Broker returns an error message to the Web browser. To avoid receiving this error message and to increase your chances of connecting when the server is very busy, increase the timeout period. The global directive Timeout overrides the default of 60 seconds. The directive ServiceTimeout further overrides the global timeout for a particular service.

Using Server Weights

If you are not using the Load Manager and you want to direct the connection to a particular machine out of a range of the servers that you have predefined, specify weights for each machine. For example, if you have two computers running Application Servers, each machine has a one-in-two chance of receiving a request from the Application Broker. The Application Broker randomly selects one of your predefined servers. To increase the likelihood that a server receives requests, assign a weight to the machine in the server directive, as shown in the following example:

   server machine_a  machine_b*5

Server A now has only a one-in-six chance of receiving a request. Server B now has a five-in-six chance. You could rewrite the previous example to show the following and attain the same result. The weight assignment of 5 eliminates the need to type the following line:

   server machine_a  machine_b  machine_b  machine_b  machine_b  machine_b

If you are using the Load Manager, you can use weights to reorder the list of servers in the service. The servers with higher weights appear first in the list that is sent to the Load Manager. Because the Load Manager always selects the first available server in the list, those with higher weights are selected first.

Specifying a Backup Machine

You can also use weights to specify a backup machine that receives requests only if the server that is running on the primary machine is not operating. To do so, set the weight to zero (0), as shown in the following example:

   server machine_a  machine_b*0

Under normal circumstances, server A acts as your primary machine and server B never receives requests. However, if server A is not operating, the Application Broker attempts to connect to server B.

Note: Weights apply to server machines and not to individual ports on those machines. You cannot force the Application Broker to favor one port over another on the same machine.

Top of Page