Note: For detailed information about tuning your applications in the Oracle Tuxedo CORBA environment, refer to the Scaling, Distributing, and Tuning CORBA Applications guide.
You Should Use MSSQ Sets If . . . You Should Not Use MSSQ Sets If . . .
3. In the RESOURCES section of the configuration file:
•
• Assign a LOAD value of 50 (LOAD=50) to any service that takes approximately the average amount of time.
• For any service taking longer than the average amount of time, set LOAD>50; for any service taking less than the average amount of time, set LOAD<50.
• Administratively—in the configuration file, you can arrange to have a log of services that are performed to be written to standard error. In the SERVICES section, specify:To analyze the information in the log, run the txrpt(1) command.For details about servopts(5) and txrpt(1), see the File Formats, Data Descriptions, MIBs, and System Processes Reference and Oracle Tuxedo Command Reference, respectively.
• Programmatically—insert a call to time() at the beginning and end of a service routine. Services that take the longest time receive the highest load; those that take the shortest time receive the lowest load. (For details about time(), see the documentation for your C language libraries.)
• Administratively—in the SERVICES section of the configuration file, specify the PRIO parameter for each service named.
• Programmatically—add calls to the tpsprio() function to the appropriate client and server applications, to allow designated clients and servers to change a priority dynamically. Only preferred clients should be able to increase the service priority. In a system on which servers perform service requests, the server can call tpsprio() to increase the priority of its interface or service calls so the user does not wait in line for every interface or service request that is required.The PRIO parameter determines the priority of an interface or a service on a server’s queue. It should be used cautiously. Once priorities are assigned, it may take longer for some messages to be dequeued. Depending on the order of messages on the queue (for example, A, B, and C), some (such as A and B) are dequeued only one in ten times when there are more than 10 requests for C. This means reduced performance and potential slow turnaround time for some services.When you are deciding whether to use the PRIO parameter, keep the following implications in mind:
• Functional similarity—if multiple services play a similar 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. In the bankapp application, for example, the WITHDRAW, DEPOSIT, and INQUIRY services are all operations that can be grouped together in a “bank teller operations” server. Administration of services is simplified when functionally similar services are bundled.
• Similar libraries—less disk space is required if you bundle services that use the same libraries. For example, if you have three services that use the same 100K library and three services that use different 100K libraries, bundling the first three services saves 200K. Functionally equivalent services often use similar libraries.
• Filling the queue—bundle only as many services into a server as the queue can handle. Each service added to an unfilled MSSQ set may add relatively little to the size of an executable, and nothing to the number of queues in the system. Once the queue is filled, however, system performance is degraded and you must create more executables to compensate.Do not put two or more services that call each other, that is, call-dependent services, in the same server. If you do so, the server issues a call to itself, causing a deadlock.The following performance enhancement controls can be applied to Oracle Tuxedo release 8.0 or later.The SICACHEENTRIESMAX option has been added to the MACHINES and SERVERS sections of the configuration file to allow you to define the maximum number of service cache entries that any process and/or server can hold.Since caching may not be useful for every client or every application, the TMSICACHEENTRIESMAX environment variable has been added to control the cache size. The default value for TMSICACHEENTRIESMAX is preconfigured so that no administrative changes are necessary when upgrading from previous releases. TMSICACHEENTRIESMAX can also control the number of cache entries, since it is not desirable for clients to grow too large.
Notes: For more information about the SICACHEENTRIESMAX option, refer to the UBBCONFIG(5)and TM_MIB(5) sections in the File Formats, Data Descriptions, MIBs, and System Processes Reference.For more information about the TMSICACHEENTRIESMAX variable, refer to the tuxenv(5)section in the File Formats, Data Descriptions, MIBs, and System Processes Reference.For Oracle Tuxedo release 8.0 or later, the NO_AA option has been added to the OPTIONS parameter in the RESOURCES section of the configuration file. The NO_AA option will circumvent the calling of the authorization and auditing security functions. Since most applications need authentication, this feature cannot be turned off.
• The parameters NONE, APP_PW, and USER_AUTH parameters will continue to work properly—except that no authorization or auditing will be done.
• The ACL and MANDATORY_ACL parameters will continue to work properly, but will only use the default Oracle security mechanism.
Note: For more information about the NO_AA option, refer to the UBBCONFIG(5)and TM_MIB(5) sections in the File Formats, Data Descriptions, MIBs, and System Processes Reference.Because only one Bridge process is running per host machine in a multiple machine Tuxedo domain, all traffic from a host machine passes through a single Bridge process to all other host machines in the domain. The Bridge process supports both single-threaded and multithreaded execution capabilities. The availability of multithreaded Bridge processing improves the data throughput potential. To enable multithreaded Bridge processing, you can configure the BRTHREADS parameter in the MACHINES section of the UBBCONFIG file.Setting BRTHREADS=Y configures the Bridge process for multithreaded execution. Setting BRTHREADS=N or accepting the default N, configures the Bridge process for single-threaded execution.
• If BRTHREADS=Y and the Bridge environment contains TMNOTHREADS=Y, the Bridge starts up in threaded mode and logs a warning message. Basically, BRTHREADS overrides TMNOTHREADS and the warning message states that the Bridge is ignoring the TMNOTHREADS setting.
Note: In a Tuxedo multiple-machine domain, setting BRTHREADS=Y has no effect for a machine that is running an earlier version of Tuxedo.For more information about the multithreaded Bridge, see the BRTHREADS parameter in the MACHINES section of the UBBCONFIG(5) in File Formats, Data Descriptions, MIBs, and System Processes Reference.To turn off multithreaded processing use the TMNOTHREADS environment variable. With this setting, individual processes can turn threads on and off without introducing a new API or flag in order to do so.If the TMNOTHREADS=Y, then the calls to the mutexing functions are avoided.
Note: For more information about TMNOTHREADS, refer to the tuxenv(5) section in File Formats, Data Descriptions, MIBs, and System Processes Reference.Although not all Oracle Tuxedo applications use XA transactions, all processes pay the cost of transactional semantics by calling internal transactional verbs. To boost performance for applications that don’t use XA transactions for Oracle Tuxedo release 8.0 or later, the NO_XA flag has been has been added to the OPTIONS parameter in the RESOURCES section of the configuration file.No XA transactions are allowed when the NO_XA flag is set. It is important to remember though, that any attempt to configure TMS services in the GROUPS section will fail if the NO_XA option has been specified.
Note: For more information about the NO_XA option, refer to the UBBCONFIG(5)and TM_MIB(5) sections in the File Formats, Data Descriptions, MIBs, and System Processes Reference.
•
•
•
Table 8‑1 Parameters for Tuning IPC Resources Number of message queues is almost equal to MAXACCESSERS + number of servers with reply queues (number of servers in MSSQ set * 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.
•
•
• SANITYSCAN, BLOCKTIME, and individual transaction timeouts
• BBLQUERY and DBBLWAITThe MAXACCESSERS, MAXSERVERS, MAXINTERFACES, and MAXSERVICES parameters increase semaphore and shared memory costs, so you should carefully weigh these costs against the expected benefits before using these parameters, and choose the values that best satisfy the needs of your system. You should take into account any increased resources your system may require for a potential migration. You should also allow for variation in the number of clients accessing the system simultaneously. 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.To determine whether the default is adequate for your application, multiply the number of clients in the system times the percentage of time they are committing a transaction. If the product of this multiplication is close to 100, you should increase the value of the MAXGTT parameter. As a result of increasing MAXGTT:
• You should also increase TLOGSIZE accordingly for every machine.
• You should set MAXGTT to 0 for applications in which distributed transactions are not used.To limit the number of buffer types and subtypes allowed in the application, set the MAXBUFTYPE and MAXBUFSTYPE parameters, respectively. The current default for MAXBUFTYPE is 16. If you plan to create eight or more user-defined buffer types, you should set MAXBUFTYPE to a higher value. Otherwise, you do not need to specify this parameter; the default value is used.The current default for MAXBUFSTYPE is 32. You may want to set this parameter to a higher value if you intend to use many different VIEW subtypes.If a system is running on slow 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.
Use MAXBUFTYPE only if you create eight or more user-defined buffer types. You can use a similar method to measure service traffic. For example, when a server is started (that is, when tpsvrinit() is invoked), 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 (through 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.Client 1 requires 4 seconds to display the results. Calls to time() 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 finding implies that a queue may be clogged, a situation that can be verified by running the pq command in tmadmin.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. Knowing this, you should then be able 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.The UNIX system sar(1) command provides valuable performance information that can be used to find system bottlenecks. You can run sar(1) to do the following:The following table describes the sar(1) command options.
Note: Some flavors of the UNIX system do not support the sar(1) command, but offer equivalent commands, instead. BSD, for example, offers the iostat(1) command; Sun offers perfmeter(1).
• “Creating the Configuration File for a Distributed ATMI Application” in Setting Up an Oracle Tuxedo Application
•