|
|
This topic includes the following sections:
For more information about monitoring WLE applications, see "Monitoring a Running System" in the Administration Guide.
Making correct decisions in the following areas can improve the functioning of your WebLogic Enterprise (WLE) or BEA TUXEDO applications:
Maximizing Application Resources
Note:
MSSQ sets are not supported in WLE.
Table 6-1 describes when to use MSSQ sets with BEA TUXEDO servers.
When to Use MSSQ Sets (TUXEDO Servers Only)
This topic includes the following sections:
Enabling Load Balancing
On BEA TUXEDO systems, you can control whether a load balancing algorithm is used on the system as a whole. With load balancing, a load factor is applied to each service within the system, and you can track the total load on every server. Every service request is sent to the qualified server that is least loaded.
Note:
On WLE systems, load balancing is enabled automatically. You cannot disable load balancing by specifying LDBAL=N
.
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 You can measure service performance time in one of the following ways:
About Load Balancing
Two Ways to Measure Service Performance Time (TUXEDO Servers Only)
To configure replicated server processes and groups in the WLE domain:
Configuring Replicated Server Processes and Groups
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
Administration Guide.Note: The MAX parameter controls the maximum number of instances. However, WLE 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.
This topic includes the following sections:
For more information about multithreaded Java servers, see Using Multithreaded Java Servers (Java only).
To configure a multithreaded Java server, you must add Threads=true
to the OPENINFO
parameter in the GROUPS
section of the UBBCONFIG
file, as shown in the following example:
OPENINFO="ORACLE_XA:Oracle_XA+Acc=P/scott/tiger+SesTm=100+LogDir=.+MaxCur=5+Threads=true" You can establish the number of threads for a Java server application by using the -M option
to the JavaServer
parameter. This parameter is used in the SERVERS
section of the application's UBBCONFIG
file. For a description of the -M
options, see "Creating a Configuration File" in the For multithreaded WLE Java servers, you must account for the number of worker threads that each server is configured to run. Worker threads are threads that are started and managed by the WLE Java software, as opposed to threads started and managed by an application program. Internally, WLE Java manages a pool of available worker threads. When a client request is received, an available worker thread from the thread pool is scheduled to execute the request. There is one thread per active object, and while the object is active, the thread is busy. When the request is done, the worker thread is returned to the pool of available threads.
The MAXACCESSERS
parameter in the application's UBBCONFIG
file sets the maximum number of concurrent accessors of a WLE system. Accessors include native and remote clients, servers, and administration processes.
A single-threaded server counts as one accessor. For a multithreaded Java server, the number of accessors can be up to twice the maximum number of worker threads that the server is configured to run, plus one for the server itself. However, to calculate a MAXACCESSERS
value for a WLE system running multithreaded servers, do not simply double the existing MAXACCESSERS
value of the whole system. Instead, you add up the accessors for each multithreaded server.
For example, assume that you have three multithreaded Java servers in your system:
Setting the OPENINFO Parameter
Configuring the Number of Threads
Configuring the Number of Concurrent Accessors
The accessor requirement of these servers is calculated by using the following formula:
[(3*2) + 1] + [(4*2) + 1] + [(5*2) + 1] = 27 accessors
This topic includes the following sections:
Assigning Priorities to Interfaces or Services
You can exert significant control over the flow of data in an application by assigning priorities to BEA TUXEDO services using the PRIO
parameter. For an application running on a BEA TUXEDO system, you can specify the PRIO
parameter for each service named in the SERVICES
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.
For TUXEDO and native C++ CORBA applications (but not Java applications), you can also dynamically change a priority with the tpsprio()
call. 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 should be used cautiously. 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:
About Priorities to Interfaces or Services
Characteristics of the PRIO Parameter
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.
This topic includes the following sections:
Bundling Services into Servers (TUXEDO Servers Only)
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.
You should bundle services for the following reasons:
About Bundling Services
When to Bundle Services
This topic includes the following sections:
Enhancing Efficiency with Application Parameters
You can set the following application parameters to enhance the efficiency of your system:
The MAXACCESSERS
, 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 WLE Java servers, you must account for the number of worker threads that each server is configured to run. The MAXACCESSERS
parameter sets the maximum number of concurrent accessors of a WLE system. Accessors include native and remote clients, servers, and administration processes.
A single-threaded server counts as one accessor. For a multithreaded Java server, the number of accessors can be up to twice the maximum number of worker threads that the server is configured to run, plus one for the server itself. However, to calculate a MAXACCESSERS
value for a WLE system running multithreaded servers, do not simply double the existing MAXACCESSERS
value of the whole system. Instead, you add up the accessors for each multithreaded server.
For example, assume that your system has three multithreaded Java servers:
Setting the MAXACCESSERS, MAXSERVERS, MAXINTERFACES, and MAXSERVICES Parameters
The accessor requirement of these servers is calculated by using the following formula:
[(3*2) + 1] + [(4*2) + 1] + [(5*2) + 1] = 27 accessors
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.
Table 6-3 describes the system parameters available for tuning an application.
Setting the MAXGTT, MAXBUFTYPE, and MAXBUFSTYPE Parameters
Setting the SANITYSCAN, BLOCKTIME, BBLQUERY, and DBBLWAIT Parameters
Setting Application Parameters
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:
Determining IPC Requirements
Table 6-4 describes the system parameters that affect the IPC needs of an application.
This topic includes the following sections:
Measuring System Traffic
For more information about monitoring WLE applications and measuring traffic, see "Monitoring a Running System" in the 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.
Note:
For CORBA C++ applications, use the Server::initialize()
and Server::release()
operations. For CORBA Java, EJB, and RMI applications, use the Server.initialize
and Server.release
methods.
In BEA 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.
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:
About System Traffic and Bottlenecks
Example of Detecting a System Bottleneck
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:
Detecting Bottlenecks on UNIX
Table 6-5 describes the sar
(1) command options.
Note:
Some UNIX platforms do not provide the sar
(1) command, but offer equivalent commands instead. BSD, for example, offers the iostat
(1) command. Sun offers perfmeter
(1).
On Windows NT, use the Performance Monitor to collect system information and detect bottlenecks. Click the Start button and select Programs, then Administration Tools, and then click NT Performance Monitor.
Detecting Bottlenecks on Windows NT
|
Copyright © 1999 BEA Systems, Inc. All rights reserved.
|