|
|
|
|
|
|
Tuning Performance
The following sections describe how to tune the performance of your WebLogic Integration deployment:
Tuning WebLogic Integration Performance
The following sections describe how to tune WebLogic Integration performance:
Primary Tuning Resources
This section describes the primary WebLogic Integration resources that you can tune to manage the work that a server performs:
In addition, the J2EE-CA resource pool size should be set for each adapter. For information about how to tune an adapter, see the documentation for the adapter.
All other WebLogic Integration resources should be changed only to support these primary resources.
Tuning WebLogic Server Performance
The following sections describe how to configure WebLogic Server resources for a WebLogic Integration deployment:
For general information about tuning WebLogic Server performance, see BEA WebLogic Server Performance and Tuning at the following URL:
http://download.oracle.com/docs/cd/E13222_01/wls/docs61/perform/index.html
Configuring the Pool Size of BPM Event Listener Message-Driven Beans
The wlpi-mdb.jar file contains the pool of event listener message-driven beans that pull events off the event queue. The pool size setting controls the number of workflows executed in the WebLogic Integration system, based on incoming events. The default setting is 11 (5 unordered listeners plus 5 ordered listeners plus 1 time listener).
Use the MDBGenerator utility to set the pool size and associated queue, as described in "Configuring a Custom Java Message Service Queue" in Customizing WebLogic Integration in Starting, Stopping, and Customizing BEA WebLogic Integration.
We recommend starting with 20 beans and monitoring whether you need more. See Do You Have Enough Message-Driven Beans? for more information.
Configuring the Number of Application Integration Asynchronous Request Threads
The wlpi-ejb.jar file contains the pool of session beans used to execute workflow instances, which are described in Instance Beans. You can configure the number of asynchronous request threads by adding the following line to the wlai.properties file:
wlai.numAsyncServiceRequestProcessors=numThreads
Here, numThreads is the number of asynchronous threads required. The default is 2.
Configuring Other EJB Pool and Cache Sizes
You can tune WebLogic Integration performance by configuring EJB pool sizes and cache sizes: start with the default settings and change them as needed. From a performance standpoint, an overly large pool or cache size is generally better than an overly small one. For more information about configuring these settings, see "Deploying EJBs in the EJB Container" in Programming WebLogic EJB at the following URL:
http://download.oracle.com/docs/cd/E13222_01/wls/docs61/ejb/deploy.html
Note: The pool size of BPM event listener message-driven beans should already be configured, as described in Configuring the Pool Size of BPM Event Listener Message-Driven Beans.
For each node in a WebLogic Integration cluster, complete the following steps:
This setting should equal or exceed the size of the BPM event listener message-driven bean pool and it should also accommodate the anticipated workload from subworkflows or Worklist clients. The default setting is 100. The full name is WorkflowProcessor in weblogic-ejb-jar.xml.
This setting should equal or exceed the number of unique templates concurrently processed in the WebLogic Integration system. The default setting is 100. The full name is TemplateDefinitionRO in weblogic-ejb-jar.xml.
This setting should equal or exceed the number of workflow instance processors. The default setting is 100. The full name is WorkflowInstance in weblogic-ejb-jar.xml.
The default setting is 200, which is generally sufficient for most deployments. The full name is com.bea.wlai.client.ApplicationView in weblogic-ejb-jar.xml.
Configuring JDBC Connection Pool Sizes
You can tune WebLogic Integration performance by configuring the size of JDBC connection pools. For an introduction, see JDBC Connection Pools.
To determine the necessary size of a JDBC connection pool on each node in a WebLogic Integration cluster, calculate the number of required connections per server, based on the guidelines in the following table.
Table 4-1 Calculating Connections for the JDBC Connection Pool
After calculating the number of connections required for each resource, calculate the sum total of all resources, and then configure the JDBC connection pool for each node in the cluster using this total.
For best performance, set the initial capacity and the maximum capacity to the same value.
You can find information on monitoring JDBC connections in Do You Have Enough JDBC Connections?
For more information about JDBC connection pools, see the following sections:
http://download.oracle.com/docs/cd/E13222_01/wls/docs61/perform/WLSTuning.html
http://download.oracle.com/docs/cd/E13222_01/wls/docs61/adminguide/jdbc.html
Configuring the Execution Thread Pool
You can tune WebLogic Integration performance by configuring the execution thread pool, which is described in Execution Thread Pool. For each node in a WebLogic Integration cluster, calculate the number of required execution threads based on the guidelines described in the following table.
Table 4-2 Calculating the Number of Execution Threads
After calculating the number of threads required for each resource, calculate the total of all resources, and then configure the thread pool size for each server, using this total. For instructions on how to configure the thread pool size using the WebLogic Server Administration Console, see "Thread Pool Size" in "Migrating WebLogic Server 6.0 Applications to WebLogic Server 6.1" in the WebLogic Server 6.1 Release Notes at the following URL:
http://download.oracle.com/docs/cd/E13222_01/wls/docs61/notes/migrate60to61.html
You can find information on monitoring threads in Do You Have Enough Threads?
Configuring Resource Connection Pools for J2EE Connector Architecture Adapters
You can tune WebLogic Integration performance by configuring the resource connection pools for J2EE Connector Architecture (J2EE-CA) adapters, which are described in J2EE Connector Architecture. For instructions on how to tune resource connection pools for a particular adapter, see the documentation for the adapter.
Configuring Large Message Support for B2B
If the messages exchanged by B2B conversations are too large to fit in memory, enable large message support on the B2B Console and restart the server. Figure 4-1 shows a portion of the console panel used for enabling large message support.
Figure 4-1 Large Message Support Area on B2B Console
Monitoring and Tuning the Java Virtual Machine (JVM) WebLogic Integration Java code is executed on the Java Virtual Machine (JVM). To achieve the optimal performance for a WebLogic Integration deployment, you need to tune the JVM configuration. For example, the JVM heap size determines how often and for how long the VM collects garbage. For WebLogic Integration, the recommended minimum heap size is 512Kb. For more information about configuring the JVM, see "Tuning Java Virtual Machines (JVMs)" in BEA WebLogic Server Performance and Tuning at the following URL: http://download.oracle.com/docs/cd/E13222_01/wls/docs61/perform/JVMTuning.html For more information about the Sun HotSpot JVM heap organization and garbage collection, go to the following URL: For a complete list of command-line options for the Sun Hotspot JVM, go to the following URL: Many of the JVM options are set in setenv.cmd or setenv.sh and startWeblogic.cmd or startweblogic.sh. Some defaults are set low in order to enable low-end systems. If you have a larger system, you can benefit from tuning the JVM up. The following sections explore commonly used options. Choosing the JVM The version of the JDK that is supplied with Weblogic Server supports two or three different JVM implementations. On Solaris systems, the Hotspot and the server JVM are supported. On Windows NT, the classic JVM is also supported. The classic JVM is not recommended because it does not provide a JIT compiler. The server runs much more slowly (at least five times) with the classic JVM than with the Hotspot or server JVM. The Hotspot and server JVM are identical except for the run-time compilation algorithms they use. (The Hotspot JVM is also known as the client JVM.) The server JVM is more appropriate for use with Weblogic Integration. Use the -server argument to specify the use of the server JVM. This argument must be the first one immediately after the Java executable name. There is a known bug that can occur with the server JVM, which causes the JVM to allocate all the available memory in the system, regardless of the heap size specified (see Sun Bug ID 4484370). If this happens, you should use Hotspot JVM, instead. Tuning JVM Heap Size The minimum (initial) and maximum sizes should be identical. For a large WebLogic Integration server, we recommend 512Mb for both values, as shown in the following option settings: On Solaris systems, there are extra options that apply to very large heaps. In particular, it is possible to bypass virtual memory and use physical memory directly for the heap. This feature is called "Intimate Shared Memory," and information about it can be found at: Garbage Collection Control on Hotspot JVM The heap space in Hotspot is cut into two parts: the new or Eden heap, and the tenured heap. All new objects are created in the Eden heap. They are moved to the tenured heap only after surviving garbage collection from the Eden heap. The tenured heap is not collected as often as the Eden heap, and the collection operation for it is a lot more expensive than collection for the Eden heap. A rule of thumb is that the Eden heap should be configured to be large enough to store temporary objects. In the case of an application server in general, and for WebLogic Integration in particular, the actual application state is kept in a database. Most memory allocated while a request is being processed is released at the end of the request. It is therefore important to configure the Eden heap to be large enough to prevent objects that are used in a single request to be moved to the tenured heap. Such a configuration also delays the need for collection on the tenured heap, which is much slower than collection on the Eden heap. (For this reason, this approach is sometimes referred to as delayed garbage collection). With a global heap of 512Mb, a reasonable size for the Eden heap is 128Mb, as shown in the following option setting: Garbage collection in the Eden heap is generational. Objects are created initially in a part of the Eden heap that contains only the young generation. Every time an object is considered for collection, but is still being used, its generation number is incremented and the object is copied to a survivor space in the Eden heap. After a number of generations, the object is declared old and moved to the tenured space. The Eden heap contains two survivor spaces, only one of which is used at a time. The number of generations that must be reached before objects are moved in the tenured heap is determined dynamically by the JVM to keep the survivor spaces half-full. The size of the survivor spaces can be specified as a ratio of the Eden heap. If survivor spaces are too small, copying collection overflows directly into the old generation. If survivor spaces are too large, they are uselessly empty. The recommended value for the survivor ratio is 2. When this value is used, each survivor space is half the size of the young generation. Because there are two survivor spaces, the space for the young generation is ½ the size of the Eden heap, and each survivor space is ¼ the size of the Eden heap. Use the following option setting to specify a survivor ratio of 2: Monitoring JVM Heap Usage The most efficient way to monitor heap usage and garbage collection is to use verbose garbage collection, selected by specifying the following flag: The output shows up on standard out. In the case of the Hotspot JVM two types of lines show up, indicating collection in the Eden (GC) or in the tenured heap (Full GC). It is also possible to use the Weblogic Server Administration Console to monitor heap utilization at run time. This helps define the heap requirements as well as identifying any memory leaks.
http://java.sun.com/docs/hotspot/gc/index.html
http://java.sun.com/docs/hotspot/VMOptions.html
-Xms512m -Xmx512m
http://java.sun.com/docs/hotspot/ism.html
-XX:NewSize=128m -XX:MaxNewSize=128m
-XX:SurvivorRatio=2
-verbosegc
Monitoring and Tuning Run-Time Performance
The following sections describe how to monitor run-time performance in a WebLogic Integration deployment:
Monitoring and Tuning WebLogic Server Performance
Use the WebLogic Server Administration Console to monitor the health and performance of your WebLogic Server domain, including such resources as servers, JDBC connection pools, JCA, HTTP, the JTA subsystem, JNDI, and EJBs. For detailed information, see "Monitoring a WebLogic Domain" in the BEA WebLogic Server Administration Guide at the following URL:
http://download.oracle.com/docs/cd/E13222_01/wls/docs61/adminguide/monitoring.html
Do You Have Enough Threads?
In the left frame of the Weblogic Server Administration Console, select Servers > server_name. In the right frame, select the Monitoring tab.
The General tab allows you to display a table with information on the execute queues, including the number of idle threads. Figure 4-2 shows how the WebLogic Server Administration Console displays information about active queues.
Figure 4-2 Active Execute Queues Table
Also under Monitoring, there is a Performance tab. This tab displays three graphs: Throughput, Queue Length, and Memory Usage. Above the graphs is the Idle Threads field. If the number shown in the Idle Threads field is sometimes zero, you need more threads. The parameter that controls the number of threads is ThreadPoolSize. The ThreadPoolSize parameter is set separately for each server. Figure 4-3 shows how the WebLogic Server Administration Console displays performance information. Figure 4-3 Server Performance Information
To add more threads, select the default queue and specify the thread count. Figure 4-4 shows how the WebLogic Server Administration Console displays execute queue information. Figure 4-4 Execute Queue Table
Figure 4-5 shows the WebLogic Server Administration Console tab used to specify the thread count. Figure 4-5 Default Execute Queue Configuration
On Solaris, you can also determine whether changing the number of threads improves performance by running the mpstat command at comparable load levels before and after changing the setting. A drop in the number of context switches suggests that performance has improved. How Many Transactions Are Occurring? To display the number of transactions of various types, select your server name in the Weblogic Server Administration Console. In the right frame, select the Monitoring tab, then the JTA tab. Select Monitor all instances. Some transactions are associated with the BPM framework, and you cannot change them. You may choose to change transaction types or combine transactions for those transactions associated with your applications. Figure 4-6 shows the WebLogic Server Administration Console tab used to monitor transactions. Figure 4-6 JTA Monitoring Tab
Server > Monitoring > JTA
Do You Have Enough JDBC Connections? JDBC connections are connections to your database, made available so that individual threads do not suffer performance problems caused by getting a new connection every time access to the database is required. You may have multiple pools of JDBC connections. It is important that each pool has enough connections so that no thread has to wait long for a connection. In the left frame, select Services > JDBC > Connection Pools. Select a pool and then select Monitor active connection pools. Look at the number of Connections; is it close to the total number of connections configured for this pool? Is the High Connections value equal to the total number of connections configured for this pool? Either of these is a sign that more connections may prove useful under similar situations or when load increases slightly. Figure 4-7 shows the WebLogic Server Administration Console window used to monitor active connection pools. Figure 4-7 Active JDBC Connection Pools
To modify connection pool configuration, go to Services > JDBC > Connection Pools > wliPool, then select Connections and set the values for the Initial Capacity and Maximum Capacity fields to the same number. Figure 4-8 shows the WebLogic Server Administration Console tab used to set initial and maximum capacity. Figure 4-8 Connection Pool Configuration
Monitoring and Tuning BPM Performance Use the WebLogic Integration Studio to monitor various aspects of workflow performance in real time, including the status of workflows and workflow variables. The Studio allows you to delete workflow instances and to view reports on workloads and performance statistics. For more information, see Monitoring Workflows in Using the WebLogic Integration Studio. Key BPM performance measurements include:
One way to obtain statistics for these performance measurements is to extract them from the database instance table using SQL statements. For example, the SQL code in the following listing calculates statistics about the number of instantiations.
Listing 4-1 SQL Code to Determine Workflow Instantiation Statistics
select 'INSTANTIATIONS', count(*),
avg((completed-started)*86400),
max((completed-started)*86400),
86400*(max(started)-min(started)) total_duration,
from instance
The SQL code in the next listing calculates statistics about the number of completions.
Listing 4-2 SQL Code to Determine Workflow Completion Statistics
select 'COMPLETIONS', count(*),
avg((completed-started)*86400),
max((completed-started)*86400),
86400*(max(completed)-min(started)) total_duration
from instance where completed is not null
Do You Have Enough Message-Driven Beans?
To display information on message-driven beans, select your server by name in the Weblogic Server Administration Console. Then, in the right frame, select the Monitoring tab, followed by the JMS tab. Select Monitor all Active JMS Servers > Active JMS Destinations > JMSServer-0.
Look at the queue length for eventQueue. If the number is often more than just a few, more queuing is occurring than is desirable for good performance. In this case, adding more MDBs helps performance. Figure 4-9 shows the WebLogic Server Administration Console tab used to monitor the event queue.
Server > Monitoring > JMS > Monitor all Active JMS Servers > Active JMS Destinations > JMSServer-0
EventQueue - Messages / Messages Received
Figure 4-9 Event Queue Monitoring
To change the number of MDBs, select EJB > wlpi-mdb-ejb.jar in the left frame of the Weblogic Server Administration Console. Then, in the right frame, select Edit EJB Descriptor. A new window is displayed showing the Max Beans in Free Pool and Initial Beans in Free Pool parameters. Edit the value of the Max Beans in Free Pool parameter. You must reboot Weblogic Server for this change to take effect. Figure 4-10 shows the WebLogic Server Administration Console tab used to edit the Max Beans in Free Pool parameter. Figure 4-10 Configuring MDBs
How Many of Each Type of Bean Does My System Have? Use the WebLogic Server Administration Console to display information bean types and quantities. In the left frame, select a particular EJB jar. In the right frame, select the Monitoring tab and the type of bean to be displayed. For example, to display information about stateful session beans, select Monitor all Stateful Session Beans. To modify the display of information, select Customize this view. You can add or delete columns and change the sort order. Add all the remaining columns. (Highlight the columns, click the arrow to move them to the right, and then press Apply.) The following columns are of particular interest: The following jar files are of particular interest: wlpi-ejb.jar, wlpi-mdb-ejb.jar, and the jar files for your application-specific EJBs. Figure 4-11, Figure 4-12, and Figure 4-13 show portions of the windows in which information for stateful, entity, and message-driven beans is displayed. Figure 4-11 Stateful Bean Information
Number of beans in use
Number of beans in cacheApplications > WLPI Application > EJB Deployment > wlpi-ejb.jar > Stateful EJBRuntimes
Figure 4-12 Entity Bean Information
Applications > WLPI Application > EJB Deployment > wlpi-ejb.jar > Entity EJBRuntimes
Figure 4-13 MDB Information
Applications > WLPI Application > EJB Deployment > wlpi-mdb-ejb.jar > Message Driven EJBRuntimes
If a system message concerning cache full is displayed, increase the corresponding bean's Max Beans in Cache parameter by editing the EJB descriptor. If many entity beans are not passivated until the cache is full, you may want to decrease the Idle Timeout Seconds parameter for the entity bean. Display the bean in the WebLogic Server Administration Console and click the Edit EJB Descriptor link. Figure 4-14 shows the WebLogic Server Administration Console tab used to edit the Idle Timeout Seconds parameter. Figure 4-14 Idle Timeout Configuration
Monitoring and Tuning B2B Integration Performance To monitor the performance of B2B integration functionality, consider the following tips:
Key performance measurements for B2B integration include:
For more information, see Monitoring B2B Integration in Administering B2B Integration.
Monitoring B2B Activity
Use the WebLogic Integration B2B Console to determine the level of B2B activity. You can monitor logs and message statistics using the WebLogic Integration B2B Console tabs shown in Figure 4-15 and Figure 4-16.
Figure 4-15 Monitoring B2B Logs
Figure 4-16 Monitoring B2B Statistics
Monitoring and Tuning AI Performance This section provides information about:
Monitoring and Tuning Application View Connections
To check whether you have sufficient connections available for your application view, start the Weblogic Server Administration Console and select Deployments > Connectors.
Select the connection factory deployed for your application view, which is named using the following format:
ApplicationViewName_connectionFactory.
Select the Monitoring tab and click Monitor all Connector Connection Pool Runtimes...
The connections to the EIS defined in your application view are displayed. These connections are made available so that individual threads do not suffer performance problems caused by getting a new connection every time access to the EIS is required. It is important that each has enough connections so that no thread has to wait long for a connection.
Look at the number of connections; is it close to the total number of connections configured for this pool? Is the Active Connections High Count value equal to the total number of connections configured for this pool? Either of these is a sign that more connections might prove useful under similar situations or when load increases slightly. Figure 4-17 shows the WebLogic Server Administration Console tab used to monitor connections.
Figure 4-17 Monitoring Application View Connection
To view or modify your maximum connections for your application view, go to the Application View Console, select your application view, and select the Deploy tab. The Maximum Pool Size value shows the maximum number of connections. Figure 4-18 shows the Application View Console tab used to monitor the maximum pool size. Figure 4-18 Monitoring Maximum Pool Size
To modify this value, perform the following steps:
Figure 4-19 shows the Application View Console tab used to edit the maximum pool size.
Figure 4-19 Modifying Maximum Pool size
Monitoring and Tuning Queues for Asynchronous Services When asynchronous services are invoked, the service responses are queued in the WLAI_ASYNC_REQUEST JMS queue. The consumers for this queue are worker threads, which are set to 2 by default. As the number of concurrent invocations increases, asynchronous service responses can start to fill up the WLAI_ASYNC_REQUEST queue. To determine whether the queue is filling up, display the Active JMS Destinations window: Check the number of messages for WLAI_ASYNC_REQUEST. Figure 4-20 shows the WebLogic Server Administration Console tab used to monitor the number of messages. Figure 4-20 Monitoring Messages for WLAI_ASYNC_REQUEST
Server > Monitoring > JMS > Monitor all Active JMS Servers > Active JMS Destinations
If messages are queuing up, increase the number of worker threads. The more you have, the more asynchronous service invocations the server can support. This parameter is set by editing the following line in the wlai.properties file: The number of processors is 2 by default, so you will likely need to increase this number. Use the following formula for calculating the number of processors that gives the theoretical maximum throughput of asynchronous requests and responses: The following table describes the values you must provide for each formula element.
wlai.numAsyncServiceRequestProcessors=2
num_async_processors = avg_clients * avg_services/sec * avg_service_duration
These averages are sometimes difficult to calculate, so you may have to estimate a value and then observe the results. In general, if your WLAI_ASYNC_REQUEST queue is filling up, you should add more processors.
Enabling Transactions and Persistence in Asynchronous Service Request/Response Handling for JMS
By default, transactions and persistence are disabled. You can enable them as required. Turn on transactions by adding or modifying the following line in the wlai.properties file:
wlai.jms.asyncServiceTransFlag=true
To enable or disable persistence, modify the WLAI_JMSConnectionFactory JMS Connection factory in the WebLogic Server Administration Console by changing the default delivery mode to Persistent or NonPersistent.
Profiling Applications
You can profile applications at run time using a Java profiler tool (such as Jprobe or OptimizeIt). Use these tools to identify performance bottlenecks and thread contentions in the system. Remember to profile run-time performance rather than boot-time performance.
Tuning Hardware, Operating System, and Network Resources
The following sections describe factors that you need to consider when you are tuning hardware, the operating system, and the network:
For detailed information, see "Tuning Hardware, Operating System, and Network Performance" in BEA WebLogic Server Performance and Tuning at the following URL:
http://download.oracle.com/docs/cd/E13222_01/wls/docs61/perform/HWTuning.html
Performance Bottlenecks
To optimize WebLogic Integration performance in a deployment, you need to understand how the following hardware resources interact with each other. Performance bottlenecks result from poor tuning of these hardware resources.
Table 4-3 Performance Bottlenecks
Tuning Hardware
To optimize WebLogic Integration performance in a deployment, consider the following hardware factors:
Tuning the Operating System
To optimize WebLogic Integration performance in a deployment, consider the following operating system factors:
Configurable TCP Tuning Parameters on Windows NT/2000
For a Windows NT or Windows 2000 server, we recommend setting the TcpTimedWaitDelay parameter to 60 seconds instead of the default 240 seconds. The parameter is in the Windows registry and can be set or modified by using the regedit utility (regedit.exe). The entry is located as follows:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
The entry is not present by default.
TcpTimedWaitDelay determines the time that must elapse before TCP can release a closed connection and reuse its resources. This period between closure and release is known as the TIME_WAIT state or 2MSL state. During this time, the connection can be reopened at much less cost to the client and server than the cost of establishing a new connection.
RFC 793 requires that TCP maintain a closed connection for an interval at least equal to twice the maximum segment lifetime (2MSL) of the network. When a connection is released, its socket pair and TCP control block (TCB) can be used to support another connection. By default, the MSL is defined to be 120 seconds, and the value of this entry is equal to two MSLs, or 4 minutes. However, you can use this registry entry to customize this interval.
Reducing the value of this entry allows TCP to release closed connections faster, providing more resources for new connections. However, if the value is too low, TCP might release connection resources before the connection is complete, requiring the server to use additional resources to reestablish the connection.
Note: Normally, TCP does not release closed connections until the value of this entry expires. However, TCP can release connections before this value expires if it is running out of TCP control blocks (TCBs). The number of TCBs the system creates is specified by the value of MaxFreeTcbs.
System Monitoring on Windows NT/2000
Use the performance monitor (perfmon.exe) for monitoring all system resources or the task manager for monitoring CPU, memory, and threads.
Swap Space Configuration for Solaris
Insufficient swap space can show up as an out-of-memory error, such as an overly small heap or thread limit.
Network Tuning for Solaris
For network tuning information for Solaris systems, see the WebLogic Server platform information page at the following location:
http://download.oracle.com/docs/cd/E13222_01/wls/platforms/sun/index.html
System Monitoring for Solaris
The following table lists the commands suggested for use in monitoring Solaris systems.
Tuning Network Performance
To optimize WebLogic Integration performance in a deployment, consider the following requirements for a high-performance network:
Tuning Databases
To optimize WebLogic Integration performance in a deployment, you need to maximize the use of underlying resources. WebLogic Integration relies extensively on database resources for handling run-time operations and ensuring that application data is durable. The following sections describe how to tune databases in a WebLogic Integration deployment:
These sections provide a checklist of issues to consider when you are working to optimize your WebLogic Integration performance. For detailed instructions about specific database products, consult the appropriate product documentation.
General Database Tuning Suggestions
The following sections explain how you can optimize database performance by adjusting the settings for various parameters and features of your deployment:
Opened Cursors
While using multiple cursors for an operation can increase concurrency in most situations (for example, one opened cursor can perform updates while another opened cursor performs inserts), there is a limit to the maximum number of cursors that can be handled by a database server. This maximum pool is shared across all sessions and connections of the database server. Keeping too many cursors opened within a single connection can starve other connections, thereby slowing database performance and reducing system scalability. A good estimate can be derived from the maximum number of opened cursors that the database server can handle and the average number of simultaneous users. Another strategy is to minimize the length of time that each cursor is kept open.
Disk I/O Optimization
Disk I/O optimization is a key database tuning parameter that is related directly to throughput and scalability. Access to even the fastest disk is orders of magnitude slower than memory access. Whenever possible, optimize the number of disk accesses. In general, selecting a larger block / buffer size for I/O reduces the number of disk accesses and might substantially increase throughput in a heavily loaded production environment.
For recommended settings, see the appropriate database-specific sections about tuning databases, which are provided later in this document.
Database Sizing and Organization of Table Spaces
Distribute the database workload across multiple disks to avoid or reduce disk overloading. To optimize database performance:
For example, each workflow instance and its children create a row in the WORKFLOWINSTANCE table. These tables need to be optimized for insert and update operations. Delete operations on this table are performed in batches through the WebLogic Integration Studio. For a batch delete operation used to remove workflow instances, be sure to configure a rollback segment with a sufficient size so that it can handle a delete operation.
Checkpointing
Checkpoint is a mechanism that periodically flushes all dirty cache data to disk. This increases the I/O activity and system resource usage for the duration of the checkpoint. While frequent checkpointing can increase the consistency of on-disk data, it can also slow database performance. While most database systems have the notion of checkpoint, not all database systems provide user-level controls. Oracle, for example, allows administrators to set the frequency of checkpoints while users have no control over SQLServer 7.X checkpoints. For recommended settings, see the product documentation for the database you are using.
Database Compatibility
Use only the recommended versions of clients and servers. For a list of supported databases, see the software requirements in the BEA WebLogic Integration Release Notes for the release of WebLogic Integration that you are using.
Database Monitoring
Monitor the following aspects of database use:
Tuning Oracle Databases
This section describes performance tuning for Oracle 8.1.7, the only version of the Oracle database supported by Weblogic Integration 2.1
V$ Tables
Oracle 8.1.7 offers a series of dynamic performance views, often called V$ tables, that allows users to monitor system statistics using SQL queries. Users need to be logged in to the database as SYS or SYSTEM, or they must have administrator privileges to access these dynamic views. Many of these dynamic views are referenced in the following sections. For details about these dynamic views, see your Oracle administrator's guide and tuning guide for details.
Initialization Parameters
The initialization parameter file (init.ora) contains the system initialization parameters and values for the Oracle server.
On Windows NT/2000, the pathname for the file is as follows:
d:\oracle\admin\sid\pfile\init.ora
where d:\oracle is the installation directory and sid is the instance ID of the database (for example, d:\Oracle\admin\hsundb\pfile\init.ora).
The contents of this file are organized as attribute-value pairs, such as PROCESSES = 100.
You should always make a backup before modifying the file. You must bounce (shut down and restart) the server to reflect any modifications.
Modifications made to this file can and should be verified after bouncing the server. This validation can be done through an SQL statement or an SQL*Plus command. The parameters and their values are stored in a dynamic performance view, V$PARAMETER.
The following query validates changes made to the PROCESSES parameter. Note that the attribute name is lower case:
SELECT name, value FROM v$parameter WHERE name = `processes'
Another method is to use the SHOW PARAMETERS parameter_name command in an SQL*Plus shell. For example, the following command:
SHOW PARAMETERS "foo"
is roughly equivalent to the following query:
SELECT name, value FROM v$parameter WHERE name LIKE `%foo%';
Ensure that you have a full understanding of the parameter before modifying its value. For detailed information about specific parameters, see your Oracle documentation.
Shared Pool Size
The share pool in an important part of the Oracle server system global area (SGA). The SGA is a group of shared memory structures that contain data and control information for one Oracle database instance. If multiple users are concurrently connected to the same instance, the data in the instance's SGA is shared among the users.
The shared pool portion of the SGA caches data for two major areas: the library cache and the dictionary cache. The library cache is used to store SQL-related information and control structures (for example, parsed SQL statement, locks). The dictionary cache is used to store operational metadata needed for SQL processing.
For most applications, the shared pool size is critical to Oracle performance. If the shared pool is too small, the server must dedicate resources to managing the limited amount of available space. This consumes CPU resources and causes contention because Oracle imposes restrictions on the parallel management of the various caches. The more you use triggers and stored procedures, the larger the shared pool must be.
The SHARED_POOL_SIZE initialization parameter specifies the size of the shared pool in bytes. We recommend a value that is no less than 9MB in a production system. It is not uncommon for systems to require up to 75MB for the shared pool. The following query monitors the amount of free memory in the share pool:
SELECT * FROM v$sgastat
WHERE name = 'free memory' AND pool = 'shared pool';
If there is always free memory available within the shared pool, then increasing the size of the pool offers little or no benefit. Also, just because the shared pool is full does not necessarily mean there is a problem. There are no entries in the shared pool that cannot be paged out once they enter the pool. Application and deployment needs may differ, thus this value needs to be tuned on the basis of specific deployments and applications.
Maximum Opened Cursors
To prevent any single connection taking all the resources in the Oracle server, the OPEN_CURSORS initialization parameter allows administrators to limit the maximum number of opened cursors for each connection. Unfortunately, the default value for this parameter is too small for systems such as WebLogic Server and WebLogic Integration. A reasonable number falls in the range of 175 to 255. Cursor information can be monitored using the following query:
SELECT name, value FROM v$sysstat
WHERE name LIKE 'opened cursor%';
Maximum Number of Processes
On most operating systems, each connection to the Oracle server spawns a shadow process to service the connection. Thus, the maximum number of processes allowed for the Oracle server must account for the number of simultaneous users, as well as the number of background processes used by the Oracle server. The default number is usually not big enough for a system that needs to support a large number of concurrent operations. A reasonable number falls in the range of 200 to 255. For platform-specific issues. see your Oracle administrator's guide. The current setting of this parameter can be obtained with the following query:
SELECT name, value FROM v$parameter WHERE name = 'processes';
Database Block Size
A block is Oracle's basic unit for storing data and the smallest unit of I/O. One data block corresponds to a specific number of bytes of physical database space on disk. This concept of a block is specific to Oracle RDBMS and should not be confused with the block size of the underlying operating system. Note that since the block size affects physical storage, this value can be set only during the creation of the database; it cannot be changed once the database has been created.
Given the nature of WebLogic Integration repository tables and access patterns, it is recommended that the database used for WebLogic Integration is created with a block size of 8K. The current setting of this parameter can be obtained with the following query:
SELECT name, value FROM v$parameter WHERE name = 'db_block_size';
The following table shows the advantages and disadvantages of commonly used block sizes.
Tuning Options for System Administrators
This section contains tuning procedures that should be performed only by system administrators or users who are intimately familiar with the affected system.
Warning: Not all tuning options in this section will have a positive effect on performance and parameter values may need to be empirically derived.
SNP Processes
By default, the Oracle server creates several background processes to perform scheduled tasks. These tasks can be scheduled only through the use of the Job Queues functionality or Advanced Replication (check your Oracle documentation for details). Thus, if you are not using these Oracle features, then the processes are wasted resources. Turn off these processes until they are actually needed. This can be done by modifying the init.ora file. The safest approach is to comment out the following section in your init.ora file:
# The following parameters are needed for the Advanced Replication Option
#job_queue_processes = 4
#job_queue_interval = 10
Sort Area Size
Increasing the sort area increases the performance of large sorts as this allows the sort to be performed in memory during query processing. This can be important, as there is only one sort area for each connection at any point in time. The default value of this init.ora parameter is usually the size of 6-8 data blocks. This value is usually sufficient for OLTP operations but should be increased for decision support operation, large bulk operations, or large index-related operations (for example, recreating an index). When performing these types of operations, you should tune the following init.ora parameters (which are currently set for 8K data blocks):
sort_area_size = 65536
sort_area_retained_size = 65536
Physical Storage Parameters for Tables
Database tables grow and shrink in size due to inserts, updates, and deletes. Growing a table incurs additional I/O that slows database operations. Thus, the physical storage parameters of each table should be set according to its expected access and usage pattern. This also means that the parameters are largely determined by the applications using the tables. In general, the default values used by Oracle work fairly well, but there are many instances where tuning these parameters can produce dramatic performance improvements. This work should be performed by a professional DBA with a deep understanding of the Oracle RDBMS. The following sections highlight some storage parameters that are common to schema objects, but are especially important to the CREATE TABLE command. It is not in the scope of this guide to recommend specific values for these parameters. (For details, see your Oracle documentation or DBA). Selected parameters are described and queries are provided to help you check for potential problems.
When a transaction modifies a block, it must first mark a flag in the header of the block. The marker is released when the transaction commits. Each marker takes space in the block, thus more transaction markers mean less space for data. Without a marker, the transaction is not allowed to modify the block and must wait. Oracle allows users to control the number of markers per block on a per-table basis. (Some tables provide users with an even finer level of control, but a description of such control is beyond the scope of this document.) The INITRANS parameter allows users to specify the initial number of markers allocated in each block (the minimum value is 1). Additional markers are allocated up to the number specified by MAXTRANS. Transactions are blocked when no free markers are available. As transactions become blocked, the possibility of deadlocks increases (that is, transactions that are not allowed to complete and hold on to resource locks). The default MAXTRANS value is 255, but it should be checked with the following query to ensure that the parameters have a reasonable value for tables involved in OLTP:
SELECT owner, table_name, ini_trans, max_trans, FROM all_tables;
These settings are important if your application involves many concurrent workflows because, during its lifecycle, each workflow executes a series of transactions against the WORKFLOWINSTANCE table.
These parameters control the size of tables as they grow and shrink. An extent is composed of one or more data blocks (see Database Block Size). These parameters control the number of extents that are allocated to a table during creation (the size of a table cannot shrink below the value specified by MINEXTENTS) and the maximum number of extents that can be allocated to a table. Generally users should create tables using the following settings:
CREATE TABLE foo (col1 number, col2 date)
STORAGE (MINEXTENTS 1 MAXEXTENTS UNLIMITED);
The following query is used to check the values of these parameters:
SELECT owner, table_name, min_extents, max_extents
FROM all_tables;
Note that when the UNLIMITED option is specified for MAXEXTENTS, the value returned by the query will be a large integer (for example, 2147483645).
Swapping of Redo Logs
To support recovery, all operations performed against the Oracle RDBMS are recorded in redo logs (unless you explicitly disable logging for certain operations). Over time, the amount of information in the log increases and eventually starts to affect the performance of each operation. Immediately after a successful database backup, the information in the redo logs is no longer necessary as recovery can be achieved with the backup. Thus, it is a good practice to start a new redo log after each backup to clean up the information that is no longer needed and potentially restore system performance. This operation can be done through the following SQL command:
ALTER SYSTEM SWITCH LOGFILE
For details about redo logging, managing redo logs and log groups, and best practices for RDBMS backup, see your Oracle documentation.
Table Reorganizations
As SQL operations (both OLTP and bulk) cause tables to grow and shrink, the storage space for the table can become fragmented. This can lead to performance degradations and requires user intervention to reclaim space gaps and compact table data. This operation is often referred to as a table reorganization. Oracle 8.1.7 does not have a built-in facility to support this operation, thus the user must perform the steps manually. Following good practices, this operation should be done soon after a database backup. The following steps show how to reorganize a table called foo:
CREATE TABLE foo_bkup AS SELECT * FROM FOO;
The act of copying the data will compact the data and since this is a new table, there is no space to reclaim.
DELETE TABLE foo;
RENAME foo_bkup TO foo
Note that each step in the process involves DDL statements (such as CREATE TABLE, DROP TABLE, and so on). DDL statements are not transactional in Oracle. More specifically, each DDL statement executes in a self-contained transaction. Thus the ROLLBACK command is ineffective during a table reorganization.
Tuning Microsoft SQL Server Databases
The following table describes performance tuning parameters that are specific to Microsoft SQL Server databases. For more information about these parameters, see your Microsoft SQL Server documentation.
Table 4-4 Performance Tuning Parameters for Microsoft SQL Server Databases
Tuning Sybase Databases
The following table describes performance tuning parameters that are specific to Sybase databases. For more information about these parameters, see your Sybase documentation.
Table 4-5 Performance Tuning Parameters for Sybase Databases
Tuning Cloudscape Databases
BEA provides Cloudscape support only for development on Windows platforms. We recommend using a database other than Cloudscape for production for the following reasons:
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|