EclipseLink provides a diverse set of features to measure and optimize application performance. You can enable or disable most features in the descriptors or session, making any resulting performance gains global.
Performance considerations are present at every step of the development cycle. Although this implies an awareness of performance issues in your design and implementation, it does not mean that you should expect to achieve the best possible performance in your first pass.
For example, if optimization complicates the design, leave it until the final development phase. You should still plan for these optimizations from your first iteration, to make them easier to integrate later.
EclipseLink provides the following means to monitor and profile performance.
The EclipseLink performance profiler helps you identify performance problems by logging performance statistics for every executed query in a given session. The Profiler is described in "Monitoring and Optimizing TopLink-Enabled Applications" in Oracle Fusion Middleware Solutions Guide for Oracle TopLink.
Use the Fetch Group Monitor to measure fetch group field usage. This can be useful for performance analysis in a complex system.
Enable this monitor using the System property org.eclipse.persistence.fetchgroupmonitor=true.
The monitor dumps the attribute used for a class every time a new attribute is accessed.
For more information about fetch groups, see Section 6.2.1, "Fetch Groups".
Use the Performance Monitor to provide detailed profiling and monitoring information in a multithreaded server environment.
Enable the monitor in persistence.xml as follows:
<property name="eclipselink.profiler" value="PerformanceMonitor"/>
The performance monitor can also be enabled through code using a SessionCustomizer.
The performance monitor will output a dump of cumulative statistics every minute to the EclipseLink log.
The statistics contains three sets of information:
Info; statistics that are constant informational data, such as the session name, or time of login.
Counter; statistics that are cumulative counters of total operations, such as cache hits, or query executions.
Timer; statistics that are cumulative measurements of total time (in nano seconds) for a specific type of operation, reading, writing, database operations.
Statistics are generally grouped in total and also by query type, query class, and query name. Counters and timers are generally recorded for the same operations, so the time per operation could also be calculated.
The time in between statistic dumps can be configured through the PerformanceMonitor API using the setDumpTime(long) API. If dumping the results is not desired, then the dumpTime attribute can be set to be very large such as Long.MAX_VALUE. The statistic can also be accessed in a Java program by using the getOperationTime(String) API.
The performance monitor can also be configured with a profile weight.
The profile weights are defined on SessionProfiler and include:
NONE; No statistics are recorded.
NORMAL; Informational statistics are recorded.
HEAVY; Informational, counter and timer statistics are recorded.
ALL; All statistics are recorded (this is the default).
Example 13-1 illustrates sample output from the Performance Monitor.
Performance Monitor:1279113281664 Operation Value (ns) Counter:CacheHits 1,375,664 Counter:CacheMisses 127 Counter:ClientSessionCreates 1,204,817 Counter:ConnectCalls 2 Counter:DataModifyQuery 48 Counter:DataModifyQuery:inventory 21 Counter:DataModifyQuery:order 27 Counter:DeleteObjectQuery 67,792 Counter:DeleteObjectQuery:Customer 1 ... Counter:ReadAllQuery 1,041,767. Counter:ReadAllQuery:Item.findByCategory 733,827 Counter:ReadAllQuery:Item.findByCategory:CacheHits 733,779 Counter:ReadAllQuery:Item.findByCategory:CacheMisses 50 ... Counter:ReadObjectQuery 1,058,273 Counter:ReadObjectQuery:Item:item 130,063 Counter:ReadObjectQuery:Item:item:CacheHits 130,063 Counter:ReadObjectQuery:Item:item:CacheMisses 1 Counter:UnitOfWorkCommits 72,568 Counter:UnitOfWorkCreates 471,491 Counter:UnitOfWorkRollbacks 1 Counter:UpdateObjectQuery 71,498 Counter:UpdateObjectQuery:Customer 62,531 ... Info:LoginTime Wed Jul 14 08:55:41 EDT 2010 Info:SessionName file:/scratch/user_domains/servers/mt-1/app.jar Timer:Caching 6,411,372,000 Timer:ConnectionManagement 17,225,641,000 Timer:DeleteObjectQuery 41,351,430,000 Timer:DeleteObjectQuery:Customer 4,441,000 Timer:DeleteObjectQuery:Customer:QueryPreparation 86,000 Timer:DeleteObjectQuery:Customer:SqlGeneration 28,000 Timer:DeleteObjectQuery:Customer:SqlPrepare 72,000 Timer:DeleteObjectQuery:Customer:StatementExecute 2,265,000 ... Timer:InsertObjectQuery 69,111,086,000 Timer:Logging 4,236,000 Timer:Merge 1,144,400,000 Timer:ObjectBuilding 31,914,397,000 Timer:QueryPreparation 984,396,000 Timer:ReadAllQuery 260,943,930,000 Timer:ReadAllQuery:Item:Item.findByCategory 14,790,333,000 Timer:ReadAllQuery:Item:Item.findByCategory:ObjectBuilding 250,959,000 Timer:ReadAllQuery:Item:Item.findByCategory:QueryPreparation 1,880,000 Timer:ReadAllQuery:Item:Item.findByCategory:RowFetch 113,552,000 Timer:ReadAllQuery:Item:Item.findByCategory:SqlGeneration 522,000 Timer:ReadAllQuery:Item:Item.findByCategory:SqlPrepare 2,055,000 Timer:ReadAllQuery:Item:Item.findByCategory:StatementExecute 107,382,000 ... Timer:Register 3,272,443,000 Timer:RowFetch 25,340,990,000 Timer:Sequencing 1,352,326,000 Timer:SqlGeneration 6,646,000 Timer:SqlPrepare 19,536,031,000 Timer:StatementExecute 508,589,220,000 Timer:TXAfterCompletion 1,854,152,000 Timer:TXBeforeCompletion 169,381,843,000 Timer:UnitOfWorkCommit 167,483,825,000 Timer:UpdateObjectQuery 46,440,589,000 Timer:UpdateObjectQuery:Customer 40,466,433,000 Timer:UpdateObjectQuery:Customer:QueryPreparation 867,496,000 Timer:UpdateObjectQuery:Customer:SqlGeneration 98,000 Timer:UpdateObjectQuery:Customer:SqlPrepare 1,319,333,000 Timer:UpdateObjectQuery:Customer:StatementExecute 32,901,366,000
Use the Query Monitor to measure query executions and cache hits. This can be useful for performance analysis in a complex system.
Enable the Query Monitor in either of these ways:
Set the System property org.eclipse.persistence.querymonitor=true.
In persistence.xml, set <property name="eclipselink.profiler" value="QueryMonitor"/>
The monitor dumps the number of query cache hits and executions (misses) once every 100 seconds.
For more information about querying, see Chapter 10, "Understanding Queries."