Managing the Network in a Distributed Application

This topic includes the following sections:

•	Running a Network for a Distributed Application

•	Compressing Data Over a Network

•	Balancing Network Request Loads

•	How to Use Data-Dependent Routing

•	How to Change Your Network Configuration

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:

•	Because messages are sent over interprocess communication (IPC) queues, the advantage of local data compression is that it results in lower utilization of IPC resources.

•	Because messages are sent over a network, the advantage of remote data compression is that it results in lower utilization of network bandwidth.

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.

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 on page 4‑2.

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

•

Consider using remote data compression if your sites are running Oracle Tuxedo release 4.2.1 or later. Your setting depends on the speed of your network. You may want to assign different settings, for example, to an Ethernet network (which is a high-speed network) and an X.25 network (which is a low-speed network).

•

For a high-speed network, consider setting remote data compression to the lowest limit for file transfers generated by the Oracle Tuxedo system. (See the note about file transfers provided later in this list.) In other words, compress only messages that are large enough to be candidates for file transfer on either the sending site or the receiving site. Note that each machine in an application may have a different limit. If this is the case, choose the lowest limit possible for each machine.

•	For a low-speed network, consider setting remote data compression to zero on all machines; that is, compress all application and system messages.

•

Consider using local data compression for sites running Oracle Tuxedo release 4.2.1 or later, even if they are interoperating with pre-release 4.2.1 sites. This results in lower utilization of IPC resources. This setting also enables you to avoid file transfers in many situations that might otherwise require a transfer and, when file transfers cannot be avoided, this setting greatly reduces the size of the files used. For more information, refer to “Message Queues and Messages” in Installing the Oracle Tuxedo System.

For local data compression, you can assign a different threshold to each machine in an application. If this is the case, always choose the lowest limit possible for each machine.

Note:

For high-traffic applications that involve a large volume of timeouts and discarding of messages due to IPC queue blocking, you may want to lower the demand of the application on the IPC queuing subsystem by having local compression done at all times.

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

•	DMCONFIG(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference

•	tuxenv(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference

•	“What Is Data Compression?” in Introducing Oracle Tuxedo ATMI

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

•	“What Is Load Balancing?” in Introducing Oracle Tuxedo ATMI

How to Use Data-Dependent Routing

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

•	Horizontally-partitioned databases

•	Rule-based servers

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

Example of Data-dependent Routing with Rule-based Servers

A banking application includes the following rules:

•	Customers can withdraw up to $500 without entering a special password.

•	Customers must enter a special password to withdraw more than $500.

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

See Also

•	“What Is Data-Dependent Routing?” in Introducing Oracle Tuxedo ATMI

•	Chapter 9, “Distributing ATMI Applications Across a Network,”in Setting Up an Oracle Tuxedo Application

•	Chapter 10, “Creating the Configuration File for a Distributed ATMI Application,”in Setting Up an Oracle Tuxedo Application

•	Chapter 11, “Setting Up the Network for a Distributed Application,” in Setting Up an Oracle Tuxedo Application

•	Scaling, Distributing, and Tuning CORBA Applications

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

•	“Operating Your Application Using Command-Line Utilities” in Introducing Oracle Tuxedo ATMI

•	tmconfig, wtmconfig(1) in the Oracle Tuxedo Command Reference

•	MIB(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference

•	TM_MIB(5) in the File Formats, Data Descriptions, MIBs, and System Processes Reference

•	“Administering Link-Level Encryption” in Using Security in CORBA Applications

•	“Administering Public Key Security” in Using Security in CORBA Applications