lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noble Paul (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-667) Alternate LRUCache implementation
Date Tue, 04 Nov 2008 04:05:44 GMT

    [ 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.


Mime
View raw message