[
https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644093#action_12644093
]
Todd Feak commented on SOLR-667:
--------------------------------
I ran with a profiler and I'm not seeing any bursts of garbage collection. It's
at a steady ~2%, with no major collections occurring (which is great!).
However, the use of the profiler also slows things down about 10-20 % which
seems to be enough that the pulsing goes away. I believe the pulsing may be
some sort of limit of the testing I'm doing on a limited local environment.
I'll include the patch in my current Solr app and do a more accurate comparison
with our production level load tests to see if it still exists. Though it may
be a while before I can provide feedback from that one, as getting machines
allocated for the heavy load testing can take a bit.
As I said before, this is a huge improvement. Thanks for all the work on this
one.
> Alternate LRUCache implementation
> ---------------------------------
>
> Key: SOLR-667
> URL: https://issues.apache.org/jira/browse/SOLR-667
> Project: Solr
> Issue Type: New Feature
> Components: search
> Affects Versions: 1.3
> Reporter: Noble Paul
> Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: ConcurrentLRUCache.java, ConcurrentLRUCache.java,
> ConcurrentLRUCache.java, SOLR-667-updates.patch, SOLR-667.patch,
> SOLR-667.patch, SOLR-667.patch, SOLR-667.patch, SOLR-667.patch,
> SOLR-667.patch, SOLR-667.patch
>
>
> The only available SolrCache i.e LRUCache is based on _LinkedHashMap_ which
> has _get()_ also synchronized. This can cause severe bottlenecks for faceted
> search. Any alternate implementation which can be faster/better must be
> considered.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
