[
https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643604#action_12643604
]
Todd Feak commented on SOLR-667:
--------------------------------
I'm not sure if that helped out. I haven't run a profiler yet ,but I think the
"pulsing" (for lack of a better term) is caused by something else.
Here's why... I used the new FastLRUCache *only* for my Document cache in my
latest test. The document cache size is large enough to hold all of the
documents in the test set, helping focus on cache behavior. The warming query
is enough to get all documents into the cache on startup. So, the cache is
essentially as full as it's gonna get. 100% hit rate, and not growing. Yet, it
still exhibits this pulsing. Could it be associated with the overhead of
maintaining the least recently used entries?
The introduction of the background thread didn't address this. It also didn't
appear to speed things up, in fact it dropped overall throughput a bit, though
still better then they old LRUCache.
> 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.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.
