[ https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644730#action_12644730 ]
Yonik Seeley commented on SOLR-667: ----------------------------------- That benchmark really isn't valid for a high number of threads though: notice the difference in hitRatio. If you have many threads quickly adding items and only one thread at a time removing items, the FastLRUCache goes over it's target size and thus increases it's hitRatio, making it artificially faster. This isn't a concern for it's use in Solr though, since the generation of a cache value will be much slower than clearing the cache. > 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.