lucene-dev mailing list archives

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


Ryan McKinley commented on SOLR-2493:

bq. I was also really confused about the design of Config (and in my opinion this is a wrong

Like many things in solr/lucene the current design is the product many incremental back-compatible
changes -- not a top down view of what it should be.  I would love to use 4.0 as a chance
to revisit configs and their relationship to xml/validation etc, but that is a load of work
with very little glory...

> 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