Version 4 (modified by 15 years ago) ( diff ) | ,
---|
Performance improvement to Search (originating from Nationaal Georegister)
Date | 2009/09/03 |
Contact(s) | Heikki Doeleman |
Last edited | Timestamp |
Status | proposal |
Assigned to release | 2.5 |
Resources | The work may be done in the NGR project |
Overview
By reducing the number of XSLT transformations, a drastic performance improvement can be achieved.
Proposal Type
- Type: Core Change
- App: GeoNetwork
- Module: Search engine
Links
- Email discussions: on geonetwork-devel: Proposals to include NGR functionality to GeoNetwork trunk
- IRC discussions: September 1st, 2009 on GeoNetwork's IRC channel
Voting History
- None as yet
Motivations
The motivations for these changes are :
1. A better performance is preferred
Proposal
In current GeoNetwork, the search from the main page works as follows: the request with search parameters is sent to GeoNetwork and is turned into a JDOM structure by Jeeves; this request object is processed in XSLT (lucene.xsl), the result of which is a different JDOM structure; this in turn is further processed in Java to create the actual Lucene query.
This proposal removes the step of XSLT processing by lucene.xsl. The function of lucene.xsl is exactly re-built in Java (LuceneQueryBuilder.java). The resulting Lucene query is not changed in this proposal.
All search types that use LuceneSearcher.java (such as search from the GUI and CSW search) are affected by this proposal, but none needs any change as the interface to LuceneSearcher.java has not changed.
LuceneQueryBuilder.java was developed test-first and as a result, it's well covered by a unit test.
A second performance gain is effected by a change to retrieving the regions data in the search service. In standard GeoNetwork, the regions are retrieved from the DB at each search request; in this proposal, it happens only once, after which the regions data is kept in memory for application lifetime.
Performance metrics from YourKit Java Profiler show that this change leads to a 90% performance increase of the search service as such (excluding the request and response handling in the Web application framework surrounding it).
TODO Jeroen says: add list of all search parameters (why? they don't change in this proposal)
Backwards Compatibility Issues
none
Risks
Participants
- As above