Jump to: navigation, search

EclipseLink/DesignDocs/221546(2.0)

< EclipseLink‎ | DesignDocs
Revision as of 09:58, 5 May 2009 by James.sutherland.oracle.com (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Design Specification: Performance and Concurrency

ER 221546

Feedback

Document History

Date Author Version Description & Notes
2009-03-24 James 0.1 Draft

Project overview

This project groups several smaller performance related bug fixes and enhancements into a single unit. Its' goal is the improve the performance, concurrency and scalability of the product.

Concepts

Performance is concerned about reducing CPU usage and finding more optimal methods of processing operations.

Concurrency is concerned with reducing contention and improving multi-threaded and multi-CPU performance.

Scalability is concerned with clustering, large workloads and data.

Requirements

The goal of this project is to ensure that our product remains the leading high-performance persistence solution. Areas of improvement are determined through performance comparison with other persistence products and benchmarking.

Specific performance investigations desired for this release:

  • JPA performance comparison with EclipseLink 1.1
  • core performance comparison with EclipseLink 1.1
  • JPA concurrency comparison with EclipseLink 1.1
  • JPA cache coordination comparison in clustered environment
  • JPA provider and app server comparison through SPECjAppServer ® benchmark.

Design Constraints

The goal of the project is to improve performance of common usage patterns. Fringe features and usage patterns will not be specifically targeted unless found to be highly deficient.

Any optimization must also be weighed in its' impact on usability, and spec compliance. Optimizations that may have a large negative impact to usability may need to be only enabled through specific configuration.

Functionality

Each specific performance improvement is discussed separately below.

Reflection Optimization

Reflection is currently used in mappings to access/set variables in the object. Reflection has some minimal overhead that can be avoided using weaved code. Reflection is also used to create instances with the default constructor. The default constructor can also perform initialization of the persistence variables which can be expensive.

ASM will be used to weave _persistence_get, _persistence_set and _persistence_new methods. An empty constructor taking the PersistenceObject as argument will also be weaved.

The get/set methods will take the attribute name and a case statement will be weaved to get/set the associated variable. The attribute name String will be interned to allow fast == comparison in the case statement. Primitives will need to be wrapped/unwrapped. Inherited fields will be forwarded to super. A special AttributeAccessor will be defined to make use of the PersistenceObject interface get/set methods, to avoid reflection. During descriptor initialization if the class was weaved as a PersistenceObject any mappings using field access will be set to use the special AttributeAccessor.

The new method will call the empty constructor, passing itself as argument to avoid naming conflicts in the constructor. During initialization if the class was weaved as a PersistenceObject, and only uses field access, an instance of the class will be created to use as the factory. A special InstantiationPolicy will be set that avoid any reflection usage.

Reflection will be weaved by default when using field access. It can be disabled using the "eclipselink.weaving.internal"="false" persistence unit property.

A potential issue for the empty constructor is if the class inits transient variables, if this becomes an issue transient variables will need to be detected and the PersistenceObject InstantiationPolicy not used.

Improved Connection Pool

The connection pool will be improved to allow configuration of a shared read/write pool, and provide an initial option. The default size will also be increased to a min and max of 32 connection, but an initial of 1 connection. ConnectionPool will be changed to use the tail of the queue, or a "hot" connection.

See, Bug#270802

Cache Coordination Configuration

Configuration support for cache coordination will be added to the persistence unit properties (persistence.xml).

Bootstrap Performance

Currently a temporary class loader and Java reflection are used to parse the annotations and class metadata. This has a number of drawbacks, including all of the classes must be loaded on the temporary or main loader adding a performance overhead. Also Java reflection does not give access to annotation unspecified values (they are always defaulted). Some application servers or environments do not support the temporary class loader. There is also the risk of class overlap between the temporary and main class loaders, causing a class to be loaded on the main class loader before it is weaved.

The metadata reflection usage will be changed to use ASM to gather the class and annotation metadata from the class byte codes.

Testing

Both the existing performance and concurrency tests and pubic benchmarks will be used to monitor and evaluate performance improvements.

Specific performance testing desired for this release:

  • JPA performance comparison with EclipseLink 1.1
  • core performance comparison with EclipseLink 1.1
  • JPA concurrency comparison with EclipseLink 1.1
  • JPA cache coordination comparison in clustered environment
  • JPA provider and app server comparison through SPECjAppServer ® benchmark.

API

Config files

persistence.xml

  • weaving property: "eclipselink.weaving.internal" = "true" | "false" , existing option, now also controls reflection and instantiation weaving.
  • connection pooling properties:
    • "eclipselink.jdbc.connections.initial"
    • "eclipselink.jdbc.connections.min"
    • "eclipselink.jdbc.connections.max"
    • "eclipselink.jdbc.write-connections.initial"
    • "eclipselink.jdbc.read-connections.initial"
    • "eclipselink.jdbc.sequence-connection-pool"
    • "eclipselink.jdbc.sequence-connection-pool.initial"
    • "eclipselink.jdbc.sequence-connection-pool.min"
    • "eclipselink.jdbc.sequence-connection-pool.max"
    • "eclipselink.jdbc.sequence-connection-pool.non-jta-data-source"
  • cache coordination properties:
    • "eclipselink.cache.coordination.protocol" = "jms" | "rmi"
    • "eclipselink.cache.coordination.jms.host" = ip
    • "eclipselink.cache.coordination.jms.topic" = name
    • "eclipselink.cache.coordination.jms.factory" = name
    • "eclipselink.cache.coordination.rmi.announcement-delay" = millis
    • "eclipselink.cache.coordination.rmi.multicast-group" = ip
    • "eclipselink.cache.coordination.rmi.multicast-group.port" = port
    • "eclipselink.cache.coordination.rmi.packet-time-to-live" = millis
    • "eclipselink.cache.coordination.rmi.url" = url
    • "eclipselink.cache.coordination.naming-service" = "jndi" | "rmi"
    • "eclipselink.cache.coordination.jndi.user" = user
    • "eclipselink.cache.coordination.jndi.password" = password
    • "eclipselink.cache.coordination.jndi.initial-context-factory" = name
    • "eclipselink.cache.coordination.remove-connection-on-error" = "true" | "false"
    • "eclipselink.cache.coordination.propagate-asynchronously" = "true" | "false"
    • "eclipselink.cache.coordination.channel" = name

GUI

Documentation

The documentation on connection pooling will need to be updated.

The documentation on weaving should mention the "eclipselink.weaving.internal" will avoid reflection usage when using field access. An an empty constructor will be used.

Open Issues

Issue # Owner Description / Notes
1 Group Should weaving of instantiation be on by default?

Decisions

Issue # Description / Notes Decision

Future Considerations

Continually improve performance.