| Oracle® Application Server Performance Guide 10g Release 3 (10.1.3.1.0) Part Number B28942-01 |
|
|
View PDF |
| Oracle® Application Server Performance Guide 10g Release 3 (10.1.3.1.0) Part Number B28942-01 |
|
|
View PDF |
This chapter covers performance information for the following Oracle Application Server areas:
Oracle TopLink (TopLink) provides features to optimize application performance, including the following important areas:
Cache Configuration: In TopLink, to avoid stale data the cache must be properly configured, and configured in conjunction with locking and query refreshing. In addition, to provide applications with high performance and scalability you should understand how the cache works, its relationship to query and transaction processing, and the cache configuration options.
Efficient Querying: In TopLink, it is important to understand the batch and join reading options on queries to ensure that minimal SQL executes, and to retrieve the graph of required objects. For searching use cases and the use of projections, you should use ReportQueries to show that only objects that may be modified or shared between requests need to be read in and cached as objects.
Efficient Transactions: In TopLink, you should understand how to use the UnitOfWork to minimize transaction scope and thus commit cycles.
The TopLink documentation includes information on these important TopLink performance areas. See the appropriate chapters in the documentation for more information about tuning your application to optimize TopLink performance.
|
See Also:
|
This section describes JTA performance options, including the following topics:
Using configuration options you can control the type and level of two-phase commit logging. To change the configuration options, you can modify the transaction-manager.xml file or use the JTA Resource MBean available from the Transaction Manager page in Application Server Control Console. When you configure two-phase commit logging, you need to be aware of the transactional ramifications of turning two-phase commit logging off.
|
Note: Two-phase commit logging is off by default. When you use the default logging level, JTA resources do not support recovery and full ACID properties. |
Table 4-1 shows the two-phase commit logging configuration options that you can set in transaction-manager.xml or using the JTA Resource MBean.
Table 4-1 Two-phase Commit Logging Log Type Configuration Options
| Log Type | Description | Performance Notes |
|---|---|---|
|
|
Specifies no logging (or recovery). This is the default value. |
When recovery and ACID properties are not required, use this option for best performance. |
|
|
File logging specifies logging to the file system for transaction recovery. |
File logging typically performs better than database logging, due to lower overhead. |
|
|
Database logging specifies logging to an Oracle database for transaction recovery. |
File logging typically performs better than database logging. |
|
See Also: See the Oracle Containers for J2EE Services Guide for more information on setting two-phase commit logging configuration options, and for the details on the transactional and recovery ramifications of specifying different log type configuration options. |
Table 4-2 describes the performance settings for file store logging that you can set in transaction-manager.xml or using the JTA Resource MBean. The default settings are adequate if the maximum concurrent number of two-phase commit transactions is less than 256.
To determine the maximum concurrent number of two-phase commit transactions, you can use the TwoPhaseCommitCompletion.maxActive metric from the JTAResource metric table.
Table 4-2 JTA File Store Logging Parameters
| Parameter | Description | Performance Notes |
|---|---|---|
|
|
Specifies the maximum number of file descriptors that can remain open or active; when this number is exceeded the oldest file descriptors are released until the xid is requested again. Avoid exceeding the Default Value: 256 |
The optimal value is large enough to cover the maximum number of concurrent requests that use two-phase commit transactions (plus a small additional number of files that may be required for recovery). The |
|
|
Specifies the number of files that are pre-allocated to the pool during startup. Default Value: 40 |
The optimal value is large enough to handle the maximum number of concurrent two-phase commit requests. Note: if the maximum concurrency is large, then to avoid a high cost at startup, you can increase this value from the default, but set the value to something smaller than |
|
|
Specifies the number of the oldest file handles which are closed when Default Value: 20 |
If you expect that you will repeatedly exceed the |
|
Note: The number specified formaxOpenFiles does not limit the number of transactions; if maxOpenFiles is exceeded, old file handles are released, but new transactions can still be created (see the oldFileReleaseSize parameter). |
This section covers the following areas:
Non-XA compliant data sources are generally faster than XA data sources. When a full XA-compliant two-phase commit is required, you must use an XA data source.
If transaction logging is set to none, any number of XA or non-XA compliant resources can be enlisted in a global transaction; however, in this case there are no ACID guarantees nor recovery.
If transaction logging is enabled, participants in a global transaction must be XA-compliant. The last resource commit feature allows for a single non-XA-compliant resource to participate in an XA transaction.
In addition to allowing a single non-XA resource to participate in a global transaction, last resource commit can also be used as a performance optimization. By enlisting an XA-capable resource as a non-XA resource and using last resource commit, a gain in performance is achieved because the resource does not need to perform XA logging. Also, the resource would never be put in doubt, that is prepared, which would prevent resources from being locked. Although last resource commit can be used as a performance optimization, it is at the cost of guaranteed correctness.
When your application uses multiple data sources to access a single resource, this can lead to unintended use of two-phase commit operations (using XA-transactions). In some cases you can improve performance by changing the configuration; this configuration change allows OC4J to eliminate two-phase commits and replace them with one-phase commits.
You can use the following metrics to check the number of one-phase commits, two-phase commits, and the count of global transactions that do not enlist any resources:
/oc4j/JTA/SinglePhaseCommitCompletion.completed /oc4j/JTA/TwoPhaseCommitCompletion.completed /oc4j/JTA/AverageCommitTime.completed
|
Note: The/oc4j/JTA/AverageCommitTime.completed metric shows all JTA involved transactions but does not show local transactions. |
Whenever there are multiple data sources used within the same global transaction, use of XA two-phase commit transactions occurs, even if the data sources actually point to the same database. If you have deployed the data sources for your application in a single database and schema, you may be able to reconfigure your application to use a single data source. This would improve performance by changing two-phase commits to single-phase commits.
Thus, transactional applications that use both traditional database resources, such as tables, and also use OJMS, where resources reside on the same database, can avoid some two-phase commits by specifying a single data source for each resource. This change should improve performance and requires that the OJMS data source configuration matches that specified for accessing the tables.
|
See Also: Oracle Containers for J2EE Services Guide for more information on Local and Global Transactions |
When you monitor JTA resources, be aware that errors can cause performance problems. You can determine if there are JTA errors by looking for Rollback or Exception counts greater than 0 using the metrics in the JTAResource metric table. For example, look at the values of the following metrics: RollbackExceptionCount, RolledbackCount, or SystemExceptionCount.
Note that certain performance problems may also affect JTA errors. For example if performance is bad, timeout errors may occur. In this case, look at the value of the metric RolledbackDueToTimedOutCount.
This section includes the following topics:
This section covers some of the important performance related EJB configuration properties specified in the orion-ejb-jar.xml configuration file that apply for Message Driven Beans (MDBs), including the following:
|
See Also: Oracle Containers for J2EE Services Guide and the chapter, Chapter, "Oracle Enterprise Messaging Service (OEMS)" for more information on using and configuring MDBs |
When you set the number JMS Connector receiver threads for an MDB, this can improve performance either when there are many concurrent users sending messages to the queue of an MDB, or when significant processing occurs in the onMessage method. For example, if the onMessage method contains code to call another EJB and the EJB processing can occur concurrently while processing other messages, then setting the JMS Connector receiver threads to a value greater than one can improve performance. Depending on the underlying JMS Connector and the specific MDB, some applications may see significant performance improvements when you increase the value of the JMS Connector ReceiverThreads configuration property.
For example, if a queue contains 100 messages, and the ReceiverThreads is set to the default value, 1, then only one MDB receiver thread processes the messages, in a serial fashion. When you set the ReceiverThreads to 5, this specifies that there can be a maximum of 5 MDB instances that take messages from the queue and process the messages in parallel. In this example, the total time required to complete the processing for the 100 messages may decrease, since in this case OC4J uses up to 5 MDB threads to dequeue and process the messages.
|
Note: The JMS ConnectorReceiverThreads value specifies a maximum value for threads; not all the threads are necessarily used, depending on the load. |
When you specify a JMS Connector ReceiverThreads value greater than 1, this enables multiple instances of the MDB to concurrently process messages from queues. However, in this case any performance improvement depends on the application and on the number of threads you specify. If you specify a value that is too large, this can cause performance to degrade due to resource contention.
|
Note: For JMS topics, always set the JMS ConnectorReceiverThreads configuration property to the value 1 (only for queues are values over 1 meaningful). |
Use JMS Connector ReceiverThreads set to the value 1 if the messages must be processed in order. If you use ReceiverThreads with a value greater than 1, messages are still removed from a queue serially, but the order of processing the messages cannot be guaranteed since the MDB is processing the messages with multiple threads.
OC4J allocates the threads used as JMS Connector receiver threads from the work manager thread pool (shown as the jca thread pool using Application Server Control Console and in server.xml) You can limit the number of JMS Connector receiver threads in the work manager thread pool using the max parameter for the jca thread pool. You can also use the min value to set the initial number of available work manager thread pool threads.
|
Performance Note: Oracle recommends leaving the jca work manager thread pool at the default setting. Thus, if you want to control concurrency for EJB MDBs, use the JMS ConnectorReceiverThreads value. |
You need to coordinate the following configuration options when you set the value for the JMS Connector ReceiverThreads:
Overall Concurrency Limit: On the system this includes all the thread-pool max threads plus either:
The sum of all the MDB JMS Connector ReceiverThreads configured for your applications deployed to OC4J (if the max for the work manager thread pool, shown as the jca thread pool, is specified at the default value, plus the sum of all threads used by other JCA adapters).
The maximum allowed number of work manager thread pool threads, shown as jca, specified with the max parameter (if this is smaller than the maximum number specified for the sum of all of the JMS Connector ReceiverThreads).
Set Minimum MDB Instances Appropriate for the Receiver Threads: There is a one-to-one correspondence between the JMS Connector ReceiverTheads created and the number of active MDB bean instances. When the initial processing time for an MDB may be significant, you should set the min-instances MDB setting to match the number of desired JMS Connector ReceiverTheads, so that these instances are initialized at startup.
Also, you should configure the MDB configuration min-instances value to be at most as large as the JMS Connector ReceiverThreads setting per MDB.
To maintain the desired number of instances, set the pool-cache-timout to a value that is large enough so that the MDB instances are not removed when idle.
The number of JMS Connector ReceiverThreads also multiplies of the number of required database connections, if any, for the MDB. For example, if a particular MDB uses 5 database connections concurrently, and there are 5 active MDB instances, then the number of requested concurrent database connections would be 25. Thus, the number of JMS Connector ReceiverThreads must be included in the calculation of the data source max-connections count.
An MDB is stateless and contains no specific client state across invocations. However, for nonclient related state, an MDB instance can contain some state across client message handling. For example, state can be maintained for a lookup. In addition, other state information that you may want to cache across onMessage invocations, such as a reference to an EJB, can be initialized in the ejbCreate method and cached to optimize MDB performance.
Remember to destroy the state in the ejbRemove method in case idle MDB objects are removed from the pool and reallocated when needed.
When MDBs use OracleAS JMS as a message provider, DMS message related metrics are available from the Oracle Application Server performance monitoring tools.For example, the OracleAS JMS JMSStoreStats metric table includes information for a destination corresponding to a queue that an MDB uses:
destination.value: name messageDequeued.count: x ops messageEnqueued.count: x ops messageCount.value: n
These metrics show the destination name, the total messages enqueued, the total number of messages dequeued, and the total number currently in the queue.
You can also check the MDB onMessage metrics to check that the time in onMessage is as expected and use the maxActive metric to see the total number of concurrent receiver threads is as expected.
client.active: 1 threads client.avg: 112 msecs client.completed: 4 ops client.maxActive: 1 threadsclient.maxTime: 70 msecsclient.minTime: 130 msecsclient.time: 121 msecs
|
Note: When monitoring a JMS destination, other applications besides the MDB may access the destination. Thus, when you test the performance of an application, make sure that you know whether the application is responsible for the message activity that is reported in the metrics. |
Application Server Control Console provides information for the performance of all MDBs and of individual MDBs.
To access the summary MDB information, do the following:
From the OC4J home page, select the Administration secondary tab.
In the table, under Services, select the JMS Providers task.
In the in the Performance area, Application Server Control Console displays the following summary information:
Active Connections Messages Waiting for Read Messages Waiting for Commit Messages Enqueued per Second Messages Dequeued per Second Messages Paged In per Second Messages Paged Out per Second Messages Committed Since Startup Messages Rolled Back Since Startup Messages Expired Since Startup
To access the individual MDB information, use the Application Server Control Console performance area:
From the OC4J home page, select the Applications secondary tab.
Select the application that you want to monitor.
In the Modules table, select the appropriate EJB module.
In the Message Driven Beans area, select the MDB you want to monitor to see the following information:
Messages Dequeued Messages Rolled Back Average Message Processing Time (seconds) Number of Available Instances Number of Used Instances
This section covers some of the available performance options for entity beans using CMP, and includes the following topics:
|
Note: This section describes several EJBs options that you can use to improve performance of your applications. This section does not describe how to set these options. For details on configuring your EJBs to use various options, refer to the Oracle Containers for J2EE Enterprise JavaBeans Developer's Guide and the Oracle TopLink Developer's Guide. |
|
See Also:
|
This section covers using efficient SQL statements and SQL querying. Table 4-3 and Table 4-4 show tuning parameters and performance recommendations related to SQL statements and querying.
Table 4-3 CMP EJBs Using Efficient SQL Statements and Querying
| Tuning Parameter | Description | Performance Notes |
|---|---|---|
|
Parameterized SQL Binding |
Using parameterized SQL and prepared statement caching, you can improve performance by reducing the number of times the database SQL engine parses and prepares SQL for a frequently called query. TopLink and OC4J/CMP does not enable parameterized SQL and prepared statement caching by default, because not all databases and JDBC drivers support these options. Note that the Oracle JDBC driver bundled with OC4J does support these options Default Value: off See Also: Oracle TopLink Developer's Guide section, "Configuring Named Query Parameterized SQL and Statement Caching at the Project Level" |
Turn SQL parameter binding on for all queries (at the project level). Oracle recommends that you enable parameterized SQL and prepared statement caching for selected databases and JDBC drivers that support these options. |
|
JDBC Statement Caching |
Statement caching is used to lower the overhead of repeated cursor creation and repeated statement parsing and creation; this can improve performance for applications using a database. Note: Use the data source statement caching (and do not use TopLink Statement Caching for CMP). Default Value: off See Also: Oracle Containers for J2EE Services Guide section, "Statement Caching with Managed Data Sources" |
You should always enable statement caching if your JDBC driver supports this option. The Oracle JDBC driver supports this option. Set this option in |
|
Fetch Size |
The JDBC fetch size gives the JDBC driver a hint as to the number of rows that should be fetched from the database when more rows are needed. For large queries that return a large number of objects you can configure the row fetch size used in the query to improve performance by reducing the number database hits required to satisfy the selection criteria. Most JDBC drivers use a default fetch size of 10. If you are reading 1000 objects, increasing the fetch size to 256 can significantly reduce the time required to fetch the query's results. Note: The default value means use the JDBC driver default value, which is typically 10 rows for the Oracle JDBC driver. Default Value: 0 See Also: Oracle TopLink Developer's Guide |
The optimal fetch size is not always obvious. Usually, a fetch size of one half or one quarter of the total expected result size is optimal. Note that if you are unsure of the result set size, incorrectly setting a fetch size too large or too small can decrease performance. |
|
Batch Writing |
Batch writing can improve database performance by sending groups of Default Value: off See Also: Oracle TopLink Developer's Guide section, "Data Access Optimization" |
Enable for all EJBs. |
Table 4-4 shows the CMR parameters for performance tuning.
Table 4-4 CMP EJBs and CMR Query Performance Options
| Tuning Parameter | Description | Performance Notes |
|---|---|---|
|
Batch Reading |
Batch reading propagates query selection criteria through an object's relationship attribute mappings. You can also nest batch read operations down through complex object graphs. This significantly reduces the number of required SQL select statements and improves database access efficiency. Default Value: off See Also: Oracle TopLink Developer's Guide section,"Using Batch Reading" |
Use for queries of tables with columns mappings to table data you also need to retrieve. You should only use either batch-reading or joining if you know that you are going to access all of the data; if you do not intend to access the relationships, then just let indirection defer their loading. Batch reading is more efficient for 1-m and other relationships as it reads less data from the database, that is, |
|
Join |
Join reading is a query optimization feature that allows a single query for a class to return the data to build the instances of that class and its related objects. Use this feature to improve query performance by reducing database access. By default, relationships are not join-read: each relationship is fetched separately when accessed if you are using indirection, or as a separate database query if you are not using indirection. Default Value: not used See Also: Oracle TopLink Developer's Guide section, "Using Join Reading" |
Use for queries of tables with columns mappings to table data you also need to retrieve. You should only use either batch-reading or joining if you know that you are going to access all of the data; if you do not intend to access the relationships, then just let indirection defer their loading. TopLink supports joining for only 1-1 and 1-m at the query level, but only 1-1 (inner) at the mapping level. For performance, Join is recommended only for joining logical 1-1 relationships. Joining is not supported to related classes that use inheritance and have subclasses that span multiple tables. |
|
Indirection |
Without indirection on, when TopLink retrieves a persistent object, it retrieves all of the dependent objects to which it refers. When you configure indirection (also known as lazy reading, lazy loading, and just-in-time reading) for an attribute mapped with a relationship mapping, TopLink uses an indirection object as a place holder for the referenced object: TopLink defers reading the dependent object until you access that specific attribute. This can result in a significant performance improvement, especially if the application is interested only in the contents of the retrieved object, rather than the objects to which it is related. Default Value: Value Holder Indirection On for all CMRs See Also: Oracle TopLink Developer's Guide section,"Indirection" |
Leave the indirection option at the default value. That is, use indirection for CMP for all situations. Querying the referenced object using Join or Batch Reading is more efficient. |
Table 4-5 shows the cache configuration options.
Table 4-5 CMP EJBs and Cache Configuration Options
| Tuning Parameter | Description | Performance Notes |
|---|---|---|
|
Object Cache |
TopLink sessions provide an object cache. CMP 2.1 applications which use the TopLink persistence manager create TopLink sessions which by default use this cache. This cache, known as the session cache, retains information about objects that are read from or written to the database, and is a key element for improving the performance of a TopLink application. Typically, a server session's object cache is shared by all client sessions acquired from it. Isolated sessions provide their own session cache isolated from the shared object cache. Default Value: enabled See Also: Oracle TopLink Developer's Guide section, "Object Cache" |
Disable (use isolated cache) for pessimistic queries. |
|
Query Result Set Cache |
In addition to the object cache in TopLink, TopLink also supports a query cache:
Default Value: not used See Also: Oracle TopLink Developer's Guide, section, "Caching Query Results in the Session Cache" |
Use for frequently executed non-primary key queries with infrequently changing result sets. Use with a cache validation timeout to refresh as needed. |
|
Cache Size |
Default Value: See Also: Oracle TopLink Developer's Guide section, "Guidelines for Configuring the Cache and Identity Maps" |
Set the cache size to be as large as the maximum number of objects (of the same type) referenced within a transaction |
|
Locking |
Oracle supports the locking policies shown in Table 4-6. Default Value: no locking See Also: Oracle TopLink Developer's Guide sections, "Configuring Locking Policy" and "Understanding Descriptors and Locking" |
. |
|
Cache Usage |
Using Cache Usage conform does not check the session cache. For read-all it first checks the database, then conforms the result with the unit of work changes and new and deleted objects. For read-object is first checks the unit of work changes and new objects for a matching object, then checks the database and then conforms the results with changes and deleted objects. Conforming is more similar to the POJO default option
Default: |
Turn Cache Usage Conform off if you do not need uncommitted data read in your transaction, especially for read-only operations, in each descriptor and at the query level if not needed. |
|
Isolation |
There is not a single tuning parameter that sets a particular database transaction isolation level in a CMP application that uses TopLink. In a typical CMP application, a variety of factors affect when database transaction isolation levels apply and to what extent a particular database transaction isolation can be achieved, including the following:
See Also: Oracle TopLink Developer's Guide section, "Database Transaction Isolation Levels" |
|
|
Cache Refreshing |
By default, TopLink caches objects read from a data source. Subsequent queries for these objects access the cache and thus improve performance by reducing data source access and avoiding the cost of rebuilding object's and their relationships. Even if a query, such as a read-all query, accesses the data source, if the objects corresponding to the records returned are in the cache, TopLink uses the cached objects. This default caching policy can lead to stale data in the application. Refreshing can be enabled at the descriptor level (
Default: No Cache Refreshing See Also: Oracle TopLink Developer's Guide section, "Configuring Cache Refreshing" |
Try to avoid descriptor level cache refresh and instead, consider configuring the following:
|
|
Note: By default, TopLink assumes that your application has exclusive access to the data it is using (that is, there are no external, nonTopLink, applications modifying the data). If your application does not have exclusive access to the data, then you need to change some of the defaults from Table 4-5. |
The default settings for CMP2.1 used with the TopLink persistence manager and cache are no locking, no cache refresh, and cache-usage conform. To assure that your application doesn't read stale data from the cache when you don't have exclusive access, and gets the required data consistency level, you need to configure these and other isolation related settings appropriately.
The locking modes, as shown in Table 4-6, along with TopLink cache-usage and query refreshing options, assures data consistency for EJB entity beans using CMP. The different combinations have both functional and performance implications, but often the functional requirements for up-to-date data and data consistency will lead to the settings for these options, even when it may be at the expense of performance.
Table 4-6 Locking Policies
| Locking Option | Description | Performance Notes |
|---|---|---|
|
No Locking |
The application does not prevent users overwriting each other's changes. This is the default locking mode.Use this mode if the Bean is never updated concurrently or concurrent reads and updates to the same rows with read-committed semantics is sufficient. See Also: Oracle TopLink Developer's Guide sections, "Configuring Locking Policy" and "Understanding Descriptors and Locking" |
In general, no locking will be faster, but may not meet your needs for data consistency |
|
Optimistic |
All users have read access to the data. When a user attempts to make a change, the application checks to ensure the data has not changed since the user read the data. See Also: Oracle TopLink Developer's Guide sections, "Configuring Locking Policy" and "Understanding Descriptors and Locking" |
|
|
Pessimistic |
The first user who accesses the data with the purpose of updating it locks the data until completing the update. See Also: Oracle TopLink Developer's Guide sections, "Configuring Locking Policy" and "Understanding Descriptors and Locking" |
If frequent concurrent updates to the same rows are expected, pessimistic locking may be faster than optimistic locking that is getting a lot of concurrent access exceptions and retries. When using pessimistic locking at the bean level, it is recommended that you use it with an isolated cache for best performance |
|
Read Only |
Setting a CMP bean descriptor to read-only ensures that the entity bean cannot be modified and allows TopLink to optimize unit of work performance. See Also: Oracle TopLink Developer's Guide sections, "Configuring Locking Policy" and "Understanding Descriptors and Locking" |
Defining a bean as read-only will perform better than a bean that is not defined as read-only, yet does no inserts, updates, or deletes, since it allows TopLink to optimize the unit of work performance. |
Check the DMS metric table type named oc4j_ejb_method and the metrics wrapper.avg or client.avg to see if your EJB methods are taking significant time (check for unexpectedly large values, as some methods you may expect to take a long time to complete). For example, check the metric values for the methods ejbCreate, create, findAll, or your application specific EJB methods.
You can also check the metrics that Application Server Control Console provides to see how the response times and transactions per second are changing over time, as follows:
From the OC4J home page, select the Applications secondary tab.
In the table, under All Applications, select the application that you want to monitor.
In the Modules table, select the EJB module of that you want to monitor.
You can also view CMP TopLink metrics for additional information on CMP performance.
|
Note: You need to set the DMS configuration OC4J command line-property-Doracle.dms.sensors to the value Heavy or All to turn on collection of TopLink related DMS metrics. |
|
See Also:
|
