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/398411"
(New page: <div style="margin:5px;float:right;border:1px solid #000000;padding:5px">__TOC__</div> = Design Specification: Performance and Concurrency = [http://bugs.eclipse.org/398411 ER 398411] [[...) |
(→Functionality) |
||
Line 43: | Line 43: | ||
Each specific performance improvement is discussed separately below. | Each specific performance improvement is discussed separately below. | ||
+ | ===Query Results Cache Invalidation=== | ||
+ | Query results caching is currently supported on any named query. | ||
+ | The query results are never invalidated when changes occur, so the cache can become out of synch with the database. | ||
+ | Note, the object is the query results are kept up to date, but if changes to the objects, or new/deleted objects affect the query results, this is not reflected. | ||
+ | The query results cache does support timeToLive and daily invalidation. | ||
+ | |||
+ | A option will be added to invalidate the query results cache, this will be enabled by default. | ||
+ | Any change (insert/update/delete) to any of the classes that the query returns will cause the query results for that query to be invalidated (cleared). | ||
+ | Changes to classes not used in the query (joins are considered used) will not affect the query results. | ||
+ | |||
+ | This is coarse grained invalidation, any insert, update or delete will cause all of the queries for that class to be invalidated, even if the query was not affected by that modification. Fine grained invalidation would be prohibitively expensive, as you would need to re-run the query in-memory on the object, but may be considered as a future enhancement. | ||
= Testing = | = Testing = |
Revision as of 11:47, 17 January 2013
Contents
Design Specification: Performance and Concurrency
Document History
Date | Author | Version Description & Notes |
---|---|---|
2013-01-17 | 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.
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.
Query Results Cache Invalidation
Query results caching is currently supported on any named query. The query results are never invalidated when changes occur, so the cache can become out of synch with the database. Note, the object is the query results are kept up to date, but if changes to the objects, or new/deleted objects affect the query results, this is not reflected. The query results cache does support timeToLive and daily invalidation.
A option will be added to invalidate the query results cache, this will be enabled by default. Any change (insert/update/delete) to any of the classes that the query returns will cause the query results for that query to be invalidated (cleared). Changes to classes not used in the query (joins are considered used) will not affect the query results.
This is coarse grained invalidation, any insert, update or delete will cause all of the queries for that class to be invalidated, even if the query was not affected by that modification. Fine grained invalidation would be prohibitively expensive, as you would need to re-run the query in-memory on the object, but may be considered as a future enhancement.
Testing
Both the existing performance and concurrency tests and pubic benchmarks will be used to monitor and evaluate performance improvements.
API
Config files
Documentation
Open Issues
Issue # | Owner | Description / Notes |
---|
Decisions
Issue # | Description / Notes | Decision |
---|
Future Considerations
Continually improve performance.