[ https://issues.apache.org/jira/browse/SOLR-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler reassigned SOLR-2493: ----------------------------------- Assignee: Uwe Schindler > 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 > > 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