[
https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644889#action_12644889
]
Noble Paul commented on SOLR-667:
---------------------------------
There is another number which we have ignored. If the cleanup is done in a
separate thread , FastLRUCache consistently outperforms the legacy one. (shalin
forgot to put the numbers). For a very large cache size , the cleanup takes
~200-300 ms. Which means a request can end up paying a huge price.
We need to add a new 'newCleanupThread' option to FastLRUCache (it is there in
my old patch). I guess with that we can make FastLRUcache the default with
newCleanupThread=true.
bq.Is there an easy way to get this patched into 1.3.0?
If you apply yonik's latest patch on trunk you get two extra files . You can
straightaway copy those two files to 1.3 and use it.
> 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: Yonik Seeley
> Fix For: 1.4
>
> Attachments: ConcurrentLRUCache.java, ConcurrentLRUCache.java,
> ConcurrentLRUCache.java, SOLR-667-alternate.patch, SOLR-667-alternate.patch,
> 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,
> 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.
