[
https://issues.apache.org/jira/browse/SOLR-12233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16443499#comment-16443499
]
Shawn Heisey commented on SOLR-12233:
-------------------------------------
Thanks for your analysis, [~dsmiley]. This issue has been an education!
What do you think of the idea of configuration to turn off implicit handlers?
(needs a new issue) For instance, I have no need for /update/csv,
/update/json, or /update/json/docs. I don't think the admin UI needs those
handlers either.
Disabling some of the implicit handlers would make Solr start a little bit
faster. For my servers, with a couple dozen cores, the difference would be
very small, but when there are thousands of cores, it could really add up.
I was thinking maybe we could create an umbrella issue for
efficiency/scalability improvements outside of SolrCloud. The issue I've just
described, and this issue, could be children of the umbrella issue.
> QParserPlugin maintains a list of classes recreated every time a Solrcore
> object is created
> -------------------------------------------------------------------------------------------
>
> Key: SOLR-12233
> URL: https://issues.apache.org/jira/browse/SOLR-12233
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 7.1.1
> Reporter: Jeff Miller
> Assignee: Erick Erickson
> Priority: Minor
> Labels: Performance, qparserplugin
> Time Spent: 10m
> Remaining Estimate: 0h
>
> QParserPlugin maintains a static map of Class Names to Class objects and
> everytime we create a SolrCore object this causes a lot of overhead doing
> classloader lookups. Our system runs a lot of cores and the classloader gets
> bogged down when a lot of threads are creating solrcore objects.
> There's no need to create these objects every time, similar classes such as
> TransformerFactory store the object one time and reference it over and over
> again
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
