This topic includes the following sections:
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 BEA Tuxedo system moves data through a network, and explains how to set the configuration file parameters that control network operations.
The BEA 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:
If you decide to use data compression, you must set the
CMPLIMIT parameter in the
MACHINES section of the configuration file, as follows:
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
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.
CMPLIMITparameter in the
TMCMPPRFMenvironment variable. The value of
TMCMPPRFMmust 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.
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:
|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.
If load balancing is turned on (that is, if
LDBAL is set to
Y in the
RESOURCES section of the application configuration file), the BEA 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.
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.
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 BEA Tuxedo CORBA application, refer to the Scaling, Distributing, and Tuning CORBA Applications guide.|
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 BEA Tuxedo system performs the following actions:
The following figure illustrates this process.
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 BEA Tuxedo system performs the following actions:
The following figure illustrates this process.
To change configuration parameters while your application is running, run the
tmconfig(1) command. This command is a shell-level interface to the BEA Tuxedo System Management Information Base (MIB).
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.