Performance improvement to Search (originating from ​Nationaal Georegister)

Date	2009/09/03
Contact(s)	​Heikki Doeleman
Last edited	Timestamp
Status	Motion passed
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

• Vote proposed September 14th 2009
• Votes:
  • Simon Pigot +1
  • François Prunayre +1
  • Jeroen Ticheler +1
  • No further objections

---

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).

Jeroen says: "add list of all search parameters". But I'm not doing it, because they are not changed in any way, in this proposal.

Backwards Compatibility Issues

none

Risks

Participants

• As above