Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Wed, 4 May 2011 21:29:03 +0000 (UTC)
From: "Stephane Bailliez (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <978018286.22925.1304544543470.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1360884420.20624.1304481483347.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (SOLR-2493) SolrQueryParser constantly parse
 luceneMatchVersion in solrconfig. Large performance hit.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/SOLR-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13028974#comment-13028974 ] 

Stephane Bailliez commented on SOLR-2493:
-----------------------------------------

The problem is hardly about naming here, it is about correctly using classes when offered the choice. Mistake was made. That's it. We expect committers to be sufficiently knowledgeable about the codebase when committing code. That's true anywhere.

You can hardly expect a service ItemService to have methods such as:

getItemFromDatabase() or getItemFromServerOnTheOtherSideOfThePlanet() or getItemFromFile() or getItemFromMemory() if there are 4 different implementations of it., you have getItem() and the 4 different implementation do something different internally.

I rather actually wonder why the config is not parsed entirely at startup rather than have nodes lying around and cherry-picked.

> SolrQueryParser constantly parse luceneMatchVersion in solrconfig. Large performance hit.
> -----------------------------------------------------------------------------------------
>
>                 Key: SOLR-2493
>                 URL: https://issues.apache.org/jira/browse/SOLR-2493
>             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(WebAppClassLoader.java:363)
>        at com.sun.org.apache.xml.internal.dtm.ObjectFactory.findProviderClass(ObjectFactory.java:506)
>        at com.sun.org.apache.xml.internal.dtm.ObjectFactory.lookUpFactoryClass(ObjectFactory.java:217)
>        at com.sun.org.apache.xml.internal.dtm.ObjectFactory.createObject(ObjectFactory.java:131)
>        at com.sun.org.apache.xml.internal.dtm.ObjectFactory.createObject(ObjectFactory.java:101)
>        at com.sun.org.apache.xml.internal.dtm.DTMManager.newInstance(DTMManager.java:135)
>        at com.sun.org.apache.xpath.internal.XPathContext.<init>(XPathContext.java:100)
>        at com.sun.org.apache.xpath.internal.jaxp.XPathImpl.eval(XPathImpl.java:201)
>        at com.sun.org.apache.xpath.internal.jaxp.XPathImpl.evaluate(XPathImpl.java:275)
>        at org.apache.solr.core.Config.getNode(Config.java:230)
>        at org.apache.solr.core.Config.getVal(Config.java:256)
>        at org.apache.solr.core.Config.getLuceneVersion(Config.java:325)
>        at org.apache.solr.search.SolrQueryParser.<init>(SolrQueryParser.java:76)
>        at org.apache.solr.schema.IndexSchema.getSolrQueryParser(IndexSchema.java:277)
> With the current 3.1 code, I do barely 250 qps with 16 concurrent users with a near empty index.
> 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: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org