lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <>
Subject [jira] [Commented] (SOLR-2493) SolrQueryParser constantly parse luceneMatchVersion in solrconfig. Large performance hit.
Date Wed, 04 May 2011 20:48:03 GMT


Robert Muir commented on SOLR-2493:

All of the "get" methods on the Config class take in xpath expressions – it should be obvious
to any one who uses them that they are going to do xpath parsing.

How is that obvious? There's definitely no javadoc saying this. In general, if you have an
api that contains XYZ and you add a getXYZ() with absolutely no javadocs that behaves as more
than a getter, thats a trap.

So I still agree with Uwe, it should be protected to prevent problems, also it would be nice
if these methods were called *parse*XYZ() instead of *get*XYZ().

Otherwise this is going to continue to happen!

> SolrQueryParser constantly parse luceneMatchVersion in solrconfig. Large performance
> -----------------------------------------------------------------------------------------
>                 Key: SOLR-2493
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>          Components: search
>    Affects Versions: 3.1
>            Reporter: Stephane Bailliez
>            Assignee: Uwe Schindler
>            Priority: Blocker
>              Labels: core, parser, performance, request, solr
>             Fix For: 3.1.1, 3.2, 4.0
>         Attachments: SOLR-2493-3.x.patch, SOLR-2493.patch
> I' m putting this as blocker as I think this is a serious issue that should be adressed
asap with a release. With the current code this is no way near suitable for production use.
> For each instance created SolrQueryParser calls
> getSchema().getSolrConfig().getLuceneVersion("luceneMatchVersion", Version.LUCENE_24)
> instead of using
> getSchema().getSolrConfig().luceneMatchVersion
> This creates a massive performance hit. For each request, there is generally 3 query
parsers created and each of them will parse the xml node in config which involve creating
an instance of XPath and behind the scene the usual factory finder pattern quicks in within
the xml parser and does a loadClass.
> The stack is typically:
>    at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(
>        at
>        at
>        at
>        at
>        at
>        at<init>(
>        at
>        at
>        at org.apache.solr.core.Config.getNode(
>        at org.apache.solr.core.Config.getVal(
>        at org.apache.solr.core.Config.getLuceneVersion(
>        at<init>(
>        at org.apache.solr.schema.IndexSchema.getSolrQueryParser(
> With the current 3.1 code, I do barely 250 qps with 16 concurrent users with a near empty
> Switching SolrQueryParser to use getSchema().getSolrConfig().luceneMatchVersion and doing
a quick bench test, performance become reasonable beyond 2000 qps.

This message is automatically generated by JIRA.
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message