Administering a Tuxedo Application at Run Time
|
 |
 |
|
 |
 |
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 BEA 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 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:
- 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.
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:
- Consider using remote data compression if your sites are running BEA 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 BEA 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 BEA 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 on page D-4 in Installing the BEA 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? on page 2-24 in Introducing BEA 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 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.
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? on page 2-30 in Introducing BEA Tuxedo ATMI
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 BEA 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 BEA Tuxedo system performs the following actions:
The following figure 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 BEA Tuxedo system performs the following actions:
The following figure illustrates this process.
Figure 4-2 Data-dependent Routing with Rule-Based Servers
See Also
- What Is Data-Dependent Routing? on page 2-24 in Introducing BEA Tuxedo ATMI
- Chapter 8, Distributing ATMI Applications Across a Network,in Setting Up a BEA Tuxedo Application
- Chapter 9, Creating the Configuration File for a Distributed ATMI Application,in Setting Up a BEA Tuxedo Application
- Chapter 10, Setting Up the Network for a Distributed Application, in Setting Up a BEA 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 BEA 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 on page 4-10 in Introducing BEA Tuxedo ATMI
- tmconfig, wtmconfig(1) in the BEA 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 on page 2-35 in Using Security in CORBA Applications
- Administering Public Key Security on page 2-41 in Using Security in CORBA Applications
