Table of Contents Previous Next PDF

Tuning CORBA Applications

Tuning CORBA Applications
This topic includes the following sections:
For more information about monitoring Oracle Tuxedo applications, see “Monitoring a Runtime System” in the Administering an Oracle Tuxedo Application at Run Time.
Technical support for third party CORBA Java ORBs should be provided by their respective vendors. Oracle Tuxedo does not provide any technical support or documentation for third party CORBA Java ORBs.
Maximizing Application Resources
Making correct decisions in the following areas can improve the functioning of your Oracle Tuxedo applications:
When to Use MSSQ Sets (Oracle Tuxedo ATMI Servers Only)
Table 4‑1 describes when to use MSSQ sets with Oracle Tuxedo servers.
The following two analogies help to show why using MSSQ sets is sometimes, but not always, beneficial:
Enabling System-controlled Load Balancing
You can control whether a load-balancing algorithm is used on the Oracle Tuxedo system as a whole. When load balancing is used, a load factor is applied to each service within the system, allowing you to track the total load on every server. Every service request is sent to the qualified server that is least loaded.
To determine how to assign load factors (located in the SERVICES section), run an application continually and calculate the average time it takes for each service to be performed. Assign a LOAD value of 50 (LOAD=50) to any service that requires the average amount of time that you calculated. Any service taking longer to execute than the calculated average should have a LOAD>50. Any service taking less to execute than the calculated average should have a LOAD<50.
A LOAD factor is assigned to each service performed, which keeps track of the total load of services that each server has performed. Each service request is routed to the server with the smallest total load. The routing of that request causes the server's total to be increased by the LOAD factor of the service requested.
You can also apply LOAD factors to interfaces. For more information about LOAD factors, see “Creating a Configuration File” in the Administering an Oracle Tuxedo Application at Run Time.
Configuring Replicated Server Processes and Groups
To configure replicated server processes and groups in the Oracle Tuxedo domain, complete the following steps:
Edit the application’s UBBCONFIG file using a text editor.
In the GROUPS section, specify the names of the groups you want to configure.
In the SERVERS section, specify the parameters in Table 4‑2 for the server process you want to replicate.
The MIN and MAX parameters determine the degree to which a given server application can process requests on a given interface in parallel. During run time, the system administrator can examine resource bottlenecks and start additional server processes, if necessary, thereby scaling the application. For more information, see “Monitoring a Running Application” in the Administering an Oracle Tuxedo Application at Run Time.
The MAX parameter controls the maximum number of instances. However, Oracle Tuxedo does not spawn instances automatically. The system will automatically start up to the specified MIN number of instances. Between MIN and MAX, the system administrator will need to spawn new instances manually. Once MAX is reached, an error will be returned by tmboot, tmadmin, or the TMIB API.
Configuring Multithreaded Servers
This topic includes the following sections:
For more information about multithreaded servers, see “Using Multithreaded Servers” on page 1‑9.
Setting the OPENINFO Parameter for Database Interoperation
To enable the use of threads by a multithreaded server when interoperating with the Oracle XA database software, you must add Threads=true to the OPENINFO parameter in the GROUPS section of the UBBCONFIG file, as shown in Listing 4‑1. For more information, see the Oracle XA online documentation.
Listing 4‑1 Adding Threads=true to the OPENINFO Parameter
Parameters Used to Configure Multithreaded Servers
The following parameters are used configure multithreaded CORBA servers. These parameters are set in UBBCONFIG file:
While the MAXOBJECTS parameter does not specifically apply to threads, you may want to increase this parameter because multithreaded applications have the potential to activate more objects at any point in time than single-threaded applications.
For a description how to set these parameters, see the following topics:
Assigning Priorities to Interfaces
This topic includes the following sections:
About Priorities to Interfaces
You can exert significant control over the flow of data in an application by assigning priorities to Oracle Tuxedo Interfaces using the PRIO parameter. For a CORBA application running on an Oracle Tuxedo system, you can specify the PRIO parameter for each interface named in the INTERFACES section of the application’s UBBCONFIG file.
For example, Server 1 offers Interfaces A, B, and C. Interfaces A and B have a priority of 50 and Interface C has a priority of 70. An interface requested for C is always dequeued before a request for A or B. Requests for A and B are dequeued equally with respect to one another. The system dequeues every tenth request in first in first out (FIFO) order to prevent a message from waiting indefinitely on the queue.
You can also dynamically change a priority with the tpsprio() call. Only preferred clients should be able to increase the interface priority. In a system on which servers perform interface request, the server can call tpsprio() to increase the priority of its interface so the user does not wait in line for every interface request that is required.
Characteristics of the PRIO Parameter
The PRIO parameter should be used carefully. Depending on the order of messages on the queue (for example, A, B, and C), some (such as A and B) will be dequeued only one in ten times. This means reduced performance and potential slow turnaround time on the service.
The characteristics of the PRIO parameter are as follows:
Assigning priorities enables you to provide more efficient service to the most important requests and slower service to the less important requests. You can also give priority to specific users or in specific circumstances.
Bundling Services into Servers (Oracle Tuxedo ATMI Servers Only)
This topic includes the following sections:
About Bundling Services
The easiest way to package services into server executables is to not package them at all. Unfortunately, if you do not package services, the number of server executables, and also message queues and semaphores, rises beyond an acceptable level. There is a trade-off between not bundling services and bundling services too much.
When to Bundle Services
You should bundle services for the following reasons:
Functional similarity—if some services are similar in their role in the application, you can bundle them in the same server. The application can offer all or none of them at a given time. An example is the bankapp application, in which the WITHDRAW, DEPOSIT, and INQUIRY services are all teller operations. Administration of services becomes simpler.
Performance Options
Performance options were added to Oracle Tuxedo in release 8.0. These options enable you to turn off specific features in the Oracle Tuxedo infrastructure. You should turn off these features only if they are not required by your CORBA or ATMI applications. Table 4‑3 describes these options.
Service and Interface Caching options (SICACHEENTRIESMAX and TMSICACHEENTRIESMAX)
Enhancing Efficiency with Application Parameters
This topic includes the following sections:
You can set these application parameters to enhance the efficiency of your system.
The MAXDISPATCHTHREADS parameter determines the maximum number of concurrently dispatched threads that each server process can spawn. When specifying this parameter, consider the following:
The value for MAXDISPATCHTHREADS determines the maximum size that the thread pool can grow to be, as it increases in size to accommodate incoming requests.
The default value for MAXDISPATCHTHREADS is 1. If you specify a value greater than 1, the system creates and uses a special dispatcher thread. This dispatcher thread is not included in the number of threads determining the maximum size of the thread pool.
Specifying a value of 1 for the MAXDISPATCHTHREADS parameter indicates that the server application should be configured as a single-threaded server. A value greater than 1 indicates that the server application should be configured as a multithreaded server.
The value you specify for the MAXDISPATCHTHREADS parameter must not be less than the value you specify for the MINDISPATCHTHREADS parameter.
The operating system resources limit the maximum number of threads that can be created in a process. MAXDISPATCHTHREADS should be less than that limit, minus the number of application managed threads that your application requires.
The value of the MAXDISPATCHTHREADS parameter affects other parameters. For example, the MAXACCESSORS parameter controls the number of simultaneous accesses to the Oracle Tuxedo system, and each thread counts as one accessor. For a multithreaded server application, you must account for the number of system-managed threads that each server is configured to run. A system-managed thread is a thread that is started and managed by the Oracle Tuxedo software, as opposed to threads started and managed by an application. Internally, Oracle Tuxedo manages a pool of available system-managed threads. When a client request is received, an available system-managed thread from the thread pool is scheduled to execute the request. When the request is completed, the system-managed thread is returned to the pool of available threads.
For example, if that you have 4 multithreaded servers in your system and each server is configured to run 50 system-managed threads, the accessor requirement for these servers is the sum total of the accessors, calculated as follows:
50 + 50 + 50 + 50 = 200 accessors
Use the MINDISPATCHTHREADS parameter to specify the number of server dispatch threads that are started when the server is initially booted. When you specify this parameter, consider the following:
The value for MINDISPATCHTHREADS determines the initial allocation of threads in the thread pool.
The separate dispatcher thread that is created when MAXDISPATCHTHREADS is greater than 1 is not counted as part of the MINDISPATCHTHREADS limit.
The value you specify for MINDISPATCHTHREADS must not be greater than the value you specify for MAXDISPATCHTHREADS.
The default value for MINDISPATCHTHREADS is 0.
The MAXACCESSERS, MAXOBJECTS, MAXSERVERS, MAXINTERFACES, and MAXSERVICES parameters increase semaphore and shared memory costs, so you should choose the minimum value that satisfies the needs of the system. You should also allow for the variation in the number of clients accessing the system at the same time. Defaults may be appropriate for a generous allocation of IPC resources. However, it is prudent to set these parameters to the lowest appropriate values for the application.
For multithreaded servers, you must account for the number of threads that each server is configured to run. The MAXACCESSERS parameter sets the maximum number of concurrent accessors of an Oracle Tuxedo system. Accessors include native and remote clients, servers, and administration processes. For more information on setting the MAXACCESSERS parameter, see “MAXDISPATCHTHREADS” on page 4‑11.
Setting the MAXGTT, MAXBUFTYPE, and MAXBUFSTYPE Parameters
You should increase the value of the MAXGTT parameter if the product of multiplying the number of clients in the system times the percentage of time they are committing a transaction is close to 100. This may require a great number of clients, depending on the speed of commit. If you increase MAXGTT, you should also increase TLOGSIZE accordingly for every machine. You should set MAXGTT to 0 for applications that do not use distributed transactions.
You can limit the number of buffer types and subtypes allowed in the application with the MAXBUFTYPE and MAXBUFSTYPE parameters, respectively. The current default for MAXBUFTYPE is 16. Unless you are creating many user-defined buffer types, you can omit MAXBUFTYPE. However, if you intend to use many different VIEW subtypes, you may want to set MAXBUFSTYPE to exceed its current default of 32.
If a system is running on slower processors (for example, due to heavy usage), you can increase the timing parameters: SANITYCAN, BLOCKTIME, and individual transaction timeouts. If networking is slow, you can increase the value of the BLOCKTIME, BBLQUERY, and DBBLWAIT parameters.
Setting Application Parameters
Table 4‑4 describes the system parameters available for tuning an application.
Increase MAXGTT for many clients; set MAXGTT to 0 for nontransactional applications.
Use MAXBUFTYPE only if you create eight or more user-defined buffer types.
If you use many different VIEW subtypes, increase the value of MAXBUFSTYPE.
Determining IPC Requirements
The values of different system parameters determine IPC requirements. You can use the tmboot -c command to test a configuration’s IPC needs. The values of the following parameters affect the IPC needs of an application:
RQADDR (that allows MSSQ sets to be formed)
Table 4‑5 describes the system parameters that affect the IPC needs of an application.
Number of message queues is almost equal to MAXACCESSERS + the number of servers with reply queues (the number of servers in MSSQ set + the number of MSSQ sets).
While MAXSERVERS, MAXSERVICES, MAXGTT, and the overall size of the ROUTING, GROUP, and NETWORK sections affect the size of shared memory, an attempt to devise formulas that correlate these parameters can become complex. Instead, simply run tmboot -c or tmloadcf -c to calculate the minimum IPC resource requirements for your application.
Measuring System Traffic
This topic includes the following sections:
For more information about monitoring Oracle Tuxedo applications and measuring traffic, see “Monitoring a Running System” in the Administering an Oracle Tuxedo Application at Run Time.
About System Traffic and Bottlenecks
Bottlenecks can occur in your system when traffic volume nears resource capacity. You can measure service traffic using a global counter in your implementation code.
For example, in Tuxedo applications, when tpsvrinit() is invoked at boot time, you can initialize a global counter and record a starting time. Subsequently, each time a particular service is called, the counter is incremented. When the server is shut down by invoking the tpsvrdone() function, the final count and the ending time are recorded. This mechanism allows you to determine how busy a particular service is over a specified period of time.
For CORBA C++ applications, use the Server::initialize() and Server::release() operations.
In Oracle Tuxedo, bottlenecks can originate from data flow patterns. The quickest way to detect bottlenecks is to begin with the client and measure the amount of time required by relevant services.
Example of Detecting a System Bottleneck
Suppose Client 1 requires 4 seconds to print to the screen. Calls to time(2) determine that the tpcall to service A is the culprit with a 3.7 second delay. Service A is monitored at the top and bottom and takes 0.5 seconds. This implies that a queue may be clogged, which was determined by using the pq command.
On the other hand, suppose service A takes 3.2 seconds. The individual parts of Service A can be bracketed and measured. Perhaps Service A issues a tpcall to Service B, which requires 2.8 seconds. It should then be possible to isolate queue time or message send blocking time. Once the relevant amount of time has been identified, the application can be retuned to handle the traffic.
Using time(2), you can measure the duration of the following:
Detecting Bottlenecks on UNIX
On UNIX systems, the sar(1) command provides valuable performance information that can be used to find system bottlenecks. You can use the sar(1) command to:
Table 4‑6 describes the sar(1) command options.
Some UNIX platforms do not provide the sar(1) command, but offer equivalent commands instead. BSD, for example, offers the iostat(1) command. Sun Microsystems, Inc. offers perfmeter(1).
Detecting Bottlenecks on Windows
On Windows, use the Performance Monitor to collect system information and detect bottlenecks. Click the Start button and select Programs, then Administration Tools, and then click Performance Monitor.

Copyright © 1994, 2017, Oracle and/or its affiliates. All rights reserved.