[
https://issues.apache.org/jira/browse/SOLR-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13028989#comment-13028989
]
Uwe Schindler commented on SOLR-2493:
-------------------------------------
We should not again fight here against each other. The problem is fixed, we
could release 3.1.1 if we fixed the last slowdown in MultiPhraseQuery.
The discussion here is just about how to prevent this. For me as a non-Solr
comitter, when I did this code with Robert last year, I was also really
confused about the design of Config (and in my opinion this is a wrong design).
We should maybe open another issue and separate parsing and value-holding in
two spearate classes (SolrConfig and ConfigParser). If we would do this all is
solved (see above).
> 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
