Administering an Oracle Tuxedo Application at Run Time

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Managing the Network in a Distributed Application

This topic includes the following sections:

 


Running a Network for a Distributed Application

Most of the work associated with running the network for a distributed application is done in the configuration or setup phase. Once you have defined the network and booted the application, the software automatically runs the network for you.

This topic describes how the Oracle Tuxedo system moves data through a network, and explains how to set the configuration file parameters that control network operations.

 


Compressing Data Over a Network

The Oracle Tuxedo system allows you to compress data being sent from one application process to another. Data compression is useful in most applications and is vital in supporting large configurations. You can use data compression when the sender and receiver of a message are on the same machine (local data compression), or when the sender and receiver of a message are on different machines (remote data compression). Both forms of compression provide advantages:

How to Set the Compression Level

If you decide to use data compression, you must set the CMPLIMIT parameter in the MACHINES section of the configuration file, as follows:

CMPLIMIT=string_value1[,string_value2]

The strings that make up the value of this parameter specify the threshold message size for messages bound to remote processes (string_value1) and local processes (string_value2). Only the first string is required. The default for both strings is the value of the MAXLONG parameter.

In addition, you have the option of setting the TMCMPPRFM parameter to establish an appropriate balance between compression and CPU performance. Higher and slower compression results in more efficient network bandwidth; lower but faster compression yields less CPU utilization.

To specify the desired level of compression, complete the following procedure.

  1. Set the compression threshold using the CMPLIMIT parameter in the UBBCONFIG configuration file.
  2. (Optional step) Set the TMCMPPRFM environment variable. The value of TMCMPPRFM must be a single digit between 1 and 9; the default is 1.
  3. A value of 1 specifies the lowest level of compression with the fastest performance; 9 represents the highest level of compression with the slowest performance. The lower the number, the more quickly the compression routine is executed.

For more information on setting the TMCMPPRFM variable, refer to tuxenv(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference.

Selecting Data Compression Thresholds

You can designate a compression threshold for messages: any messages larger than the threshold you specify are compressed. To designate a compression threshold, set the CMPLIMIT parameter. For instructions, see How to Set the Compression Level.

When choosing data compression thresholds, keep in mind the following criteria:

Because compression depends on the type of data being transmitted, we strongly recommend that you try different settings in your environment to determine which one yields the best results.

See Also

 


Balancing Network Request Loads

If load balancing is turned on (that is, if LDBAL is set to Y in the RESOURCES section of the application configuration file), the Oracle Tuxedo system attempts to balance requests across the network. Because load information is not updated globally, each site has a unique view of the load at remote sites.

Use the NETLOAD parameter in the MACHINES section of the configuration file (or the TMNETLOAD environment variable) to force more requests to be sent to local queues. The value of this parameter is a number that is added to the load for remote queues, so the remote queues appear to have more work than they do. As a result, even if load balancing is turned on, local requests are sent to local queues more often than to remote queues.

As an example, assume servers A and B offer a service with load factor 50. Server A is running on the same machine as the calling client (local), and server B is running on a different machine (remote). If NETLOAD is set to 100, approximately three requests will be sent to A for every one sent to B.

Another mechanism that affects load balancing is local idle server preference. Requests are always sent to a server on the same machine as the client, assuming that the server offers the desired service and is idle. This decision overrides any load balancing considerations, because the local server is known to be available immediately.

See Also

 


How to Use Data-Dependent Routing

Data-dependent routing is useful when clients issue service requests to:

A horizontally-partitioned database is an information repository that is divided into segments, each of which is used to store a different category of information. This arrangement is similar to a library in which each shelf of a bookcase holds books for a different category (for example, biography, fiction, and so on).

A rule-based server is a server that determines whether service requests meet certain, application-specific criteria before forwarding them to service routines. Rule-based servers are useful when you want to handle requests that are almost identical by taking slightly different actions for business reasons.

Note: For detailed information about factory-based routing for a distributed Oracle Tuxedo CORBA application, refer to the Scaling, Distributing, and Tuning CORBA Applications guide.

Example of Data-dependent Routing with a Horizontally-partitioned Database

Suppose two clients in a banking application issue requests for the current balance in two accounts: Account 3 and Account 17. If data-dependent routing is being used in the application, then the Oracle Tuxedo system performs the following actions:

  1. Gets the account numbers for the two service requests (3 and 17).
  2. Checks the routing tables on the Oracle Tuxedo bulletin board that show which servers handle which range of data. (In this example, server 1 handles all requests for Accounts 1 through 10, and server 2 handles all requests for Accounts 11 through 20.)
  3. Sends each request to the appropriate server. Specifically, the system forwards the request about Account 3 to server 1, and the request about Account 17 to server 2.

Figure 4-1 illustrates this process.

Figure 4-1 Data-dependent Routing with a Horizontally-partitioned Database

Data-dependent Routing with a Horizontally-partitioned Database

Example of Data-dependent Routing with Rule-based Servers

A banking application includes the following rules:

Two clients issue withdrawal requests: one for $100 and one for $800. If data-dependent routing is enabled to support the withdrawal rules, then the Oracle Tuxedo system performs the following actions:

  1. Gets the amount specified for withdrawal in the two service requests ($100 and $800).
  2. Checks the routing tables on the Oracle Tuxedo bulletin board that show which servers handle requests for the amount being requested. (In this example, server 1 handles all requests to withdraw amounts up to $500; server 2 handles all requests to withdraw amount over $500.)
  3. Sends each request to the appropriate server. Specifically, the system forwards the request for $100 to server 1 and the request for $800 to server 2.

Figure 4-2 illustrates this process.

Figure 4-2 Data-dependent Routing with Rule-Based Servers

Data-dependent Routing with Rule-Based Servers

See Also

 


How to Change Your Network Configuration

To change configuration parameters while your application is running, run the tmconfig(1) command. This command is a shell-level interface to the Oracle Tuxedo System Management Information Base (MIB).

Using tmconfig, you can browse and modify the TUXCONFIG file without bringing down your system. For example, you can add new components, such as machines and servers, while your application is running.

See Also


  Back to Top       Previous  Next