[
https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-667:
----------------------------
Attachment: ConcurrentLRUCache.java
my findings on a simple perf test with no contention (single thread)
The code is there in the _main()_
cache size 1 million
with Hashmap
* time taken for 1 million inserts = 2019ms
* time taken for 1 million gets = 625
* time taken for cleanup = 345ms
with ConcurrenthashHashMap
* time taken for 1 million inserts = 2437(roughly 20% slower than hashmap but
small in absolute numbers)
* time taken for 1 million gets = 393ms (actually faster than simple HashMap )
* time taken for cleanup = 298ms (actually faster)
other observations
The extra thread may not be be necessary . The unlucky put() may take around
.25 secs to .5secs for a cache size of 1 million .
If we keep the value of (highHaterMark -lowWaterMark) value very high cleanups
will be infrequent
> 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
> Attachments: ConcurrentLRUCache.java, ConcurrentLRUCache.java
>
>
> 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.
