[
https://issues.apache.org/jira/browse/SOLR-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13028642#comment-13028642
]
Uwe Schindler commented on SOLR-2493:
-------------------------------------
I also reviewed other places where luceneMatchVersion is used, all other places
are correct (SpellChecker...).
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
