Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EclipseLink/DesignDocs/298985"
(→Singleton cache keys and cache refactoring) |
(→Open Issues) |
||
Line 93: | Line 93: | ||
| 1 | | 1 | ||
| Group | | Group | ||
− | | What is the impact of the cache refactoring on | + | | What is the impact of the cache refactoring on Cache interceptors integration? |
+ | | 2 | ||
+ | | Group | ||
+ | | What is the impact of the cache refactoring on backward compatibility? | ||
|} | |} | ||
Revision as of 10:53, 7 January 2010
Design Specification: Performance and Concurrency
Document History
Date | Author | Version Description & Notes |
---|---|---|
2010-01-06 | 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 2.0
- core performance comparison with EclipseLink 2.0
- JPA concurrency comparison with EclipseLink 2.0
- 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.
Building objects from ResultSets
There is currently an old prototype of building objects directly from ResultSets. The goal of the feature is to allow "simple" objects and queries to be able to bypass the intermediate DatabaseRow objects build from JDBC used to build objects. Also to avoid a lot of the checks for non core features and simplify the object building process.
This will introduce a second path on queries and object building for these optimized queries, that should avoid a lot of the general overhead required to support advanced features. The feature will only be used on a query, or perhaps a class through configuration or if the class/query are determined to be "simple".
Initially simple will only include direct mappings, but hopefully be expanded to include single primary key relationships, or perhaps composite primary keys. It will not include inheritance, events, complex queries, fetch groups, etc.
Singleton cache keys and cache refactoring
Currently cache access can be an expensive operation. This will be improved by simplifying the CacheKey. For singleton primary key objects, the Id value (Integer, Long, String) will instead be used as the cache key. This will have a very broad impact as it changes the usage of Vector for the primary key, to be of type Object. CacheKey may then need to be refactored into a CacheValue. CacheKey will still be used for composite primary keys.
This could also allow for the JPA IdClass to be used as the cache key through configuration.
This would affect a lot of internal API, as well as some external API that currently is typed to Vector. The public API taking Vector could still be supported, but the API returning Vector would either need to be changed, or new methods added and old ones deprecated.
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 2.0
- core performance comparison with EclipseLink 2.0
- JPA concurrency comparison with EclipseLink 2.0
- JPA provider and app server comparison through SPECjAppServer ® benchmark.
API
Config files
Documentation
Open Issues
Issue # | Owner | Description / Notes | |||
---|---|---|---|---|---|
1 | Group | What is the impact of the cache refactoring on Cache interceptors integration? | 2 | Group | What is the impact of the cache refactoring on backward compatibility? |
Decisions
Issue # | Description / Notes | Decision |
---|
Future Considerations
Continually improve performance.