Monitoring and Optimizing EclipseLink-Enabled Applications

Enabling the EclipseLink Profiler

The EclipseLink performance profiler is an instance of org.eclipse.persistence.tools.profiler.PerformanceProfiler class. To enable it, add the following line to the persistence.xml file:

<property name="eclipselink.profiler" value="PerformanceProfiler.logProfiler"/>

In addition to enabling the EclipseLink profiler, The PerformanceProfiler class public API also provides the functionality described in Table 18-2:

Accessing and Interpreting Profiler Results

You can see profiling results by opening the profile log in a text reader, such as Notepad.

The profiler output file indicates the health of a EclipseLink-enabled application.

Example 18-7 shows an sample of the EclipseLink profiler output.

Begin Profile of{
ReadAllQuery(com.demos.employee.domain.Employee)
Profile(ReadAllQuery,# of obj=12, time=139923809,sql execute=21723809,
prepare=49523809, row fetch=39023809, time/obj=11623809,obj/sec=8)
} End Profile

Example 18-7 shows the following information about the query:

• ReadAllQuery(com.demos.employee.domain.Employee): specific query profiled, and its arguments.

• Profile(ReadAllQuery: start of the profile and the type of query.

• # of obj=12: number of objects involved in the query.

• time=139923809: total execution time of the query (in milliseconds).

• sql execute=21723809: total time spent executing the SQL statement.

• prepare=49523809: total time spent preparing the SQL statement.

• row fetch=39023809: total time spent fetching rows from the database.

• time/obj=116123809: number of nanoseconds spent on each object.

• obj/sec=8: number of objects handled per second.

Identifying General Performance Optimizations

Avoid overriding EclipseLink default behavior unless your application requires it. Some of these defaults are suitable for a development environment; you should change these defaults to suit your production environment. These defaults may include:

• Batch writing – See "jdbc.batch-writing" in Jakarta Persistence API (JPA) Extensions Reference for EclipseLink.

• Statement caching – See "jdbc.cache-statements" in Jakarta Persistence API (JPA) Extensions Reference for EclipseLink.

• Read and write connection pool size – See "connection-pool" in Jakarta Persistence API (JPA) Extensions Reference for EclipseLink.

• Session cache size – See "maintain-cache" in Jakarta Persistence API (JPA) Extensions Reference for EclipseLink.

Use the Workbench rather than manual coding. These tools are not only easy to use: the default configuration they export to deployment XML (and the code it generates, if required) represents best practices optimized for most applications.

Schema

Optimization is an important consideration when you design your database schema and object model. Most performance issues occur when the object model or database schema is too complex, as this can make the database slow and difficult to query. This is most likely to happen if you derive your database schema directly from a complex object model.

To optimize performance, design the object model and database schema together. However, allow each model to be designed optimally: do not require a direct one-to-one correlation between the two.

Possible ways to optimize the schema include:

• Aggregating two tables into one

• Splitting one table into many

• Using a collapsed hierarchy

• Choosing one out of many

See "Data Storage Schema" in EclipseLink Concepts for additional information.

Mappings and Descriptors

If you find performance bottlenecks in your mapping and descriptors, try these solutions:

• Always use indirection (lazy loading). It is not only critical in optimizing database access, but also allows EclipseLink to make several other optimizations including optimizing its cache access and unit of work processing. See "cache-usage" in Jakarta Persistence API (JPA) Extensions Reference for EclipseLink.

• Avoid using method access in your EclipseLink mappings, especially if you have expensive or potentially dangerous side-effect code in your get or set methods; use the default direct attribute access instead. See "Using Method or Direct Field Access" in the EclipseLink Concepts.

• Avoid using the existence checking option checkCacheThenDatabase on descriptors, unless required by the application. The default existence checking behavior offers better performance. See "@ExistenceChecking" in Jakarta Persistence API (JPA) Extensions Reference for EclipseLink.

• Avoid expensive initialization in the default constructor that EclipseLink uses to instantiate objects. Instead, use lazy initialization or use an EclipseLink instantiation policy to configure the descriptor to use a different constructor. See "@InstantiationCopyPolicy" in Jakarta Persistence API (JPA) Extensions Reference for EclipseLink.

Cache

You can often improve performance through caching, even in a clustered environment by implementing cache coordination. Cache coordination allows multiple, possibly distributed instances of a session to broadcast object changes among each other so that each session's cache can be kept up-to-date. For detailed information about optimizing cache behavior, see "Understanding Caching" in EclipseLink Concepts and the following examples:

• http://wiki.eclipse.org/EclipseLink/Examples/JPA/Caching

• http://wiki.eclipse.org/EclipseLink/Examples/JPA/CacheCoordination

• http://wiki.eclipse.org/EclipseLink/Examples/JPA/DCN

Data Access

Depending on the type of data source your application accesses, EclipseLink offers a variety of Login options that you can use to tune the performance of low level data reads and writes. For optimizing higher-level data reads and writes, "Understanding Data Access" in EclipseLink Concepts offers several techniques to improve data access performance for your application. These techniques show you how to:

• Optimize JDBC driver properties.

• Optimize data format.

• Use batch writing for optimization.

• Use Outer-Join Reading with Inherited Subclasses.

• Use Parameterized SQL (Parameter Binding) and Prepared Statement Caching for Optimization.

Queries

EclipseLink provides an extensive query API for reading, writing, and updating data. "Understanding EclipseLink Queries" in EclipseLink Concepts offers several techniques to improve query performance for your application. These techniques show you how to:

• Use parameterized SQL and prepared statement caching for optimization.

• Use named queries for optimization.

• Use batch and join reading for optimization.

• Use partial object queries and fetch groups for optimization.

• Use read-only queries for optimization.

• Use JDBC fetch size for optimization.

• Use cursored streams and scrollable cursors for optimization.

• Use result set pagination for optimization.

It also includes links to read and write optimization examples.

Application Server and Database Optimization

To optimize the application server and database performance, consider these techniques:

• Configuring your application server and database correctly can have a big impact on performance and scalability. Ensure that you correctly optimize these key components of your application in addition to your EclipseLink application and persistence.

• For your application or Jakarta EE server, ensure your memory, thread pool and connection pool sizes are sufficient for your server's expected load, and that your JVM has been configured optimally.

• Ensure that your database has been configured correctly for optimal performance and its expected load.