= Performance improvement to Search (originating from [http://nationaalgeoregister.nl Nationaal Georegister]) =

|| '''Date''' || 2009/09/03 ||
|| '''Contact(s)''' || [http://wiki.osgeo.org/wiki/User:Heikki Heikki Doeleman] ||
|| '''Last edited''' || [[Timestamp]] ||
|| '''Status''' || draft ||
|| '''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: [http://n2.nabble.com/Proposals-to-include-NGR-functionality-to-GeoNetwork-trunk-td3365623.html#a3365623 "Proposals to include NGR functionality to GeoNetwork trunk"]
 * '''IRC discussions''': [http://logs.qgis.org/geonetwork/%23geonetwork.2009-09-01.log 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 creation of the search results page).

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