[ 
https://issues.apache.org/jira/browse/SOLR-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617454#action_12617454
 ] 

Fuad Efendi commented on SOLR-665:
----------------------------------

bq. If multiple threads access this map concurrently, and at least one of the 
threads modifies the map structurally, it must be synchronized externally. (A 
structural modification is any operation that adds or deletes one or more 
mappings; merely changing the value associated with a key that an instance 
already contains is not a structural modification.)

I already commented it. Just try to avoid 'books' and 'authors', also try to 
find meaning in JavaDocs and try to browse JavaSource instead...

- _structural_  _modification_, related _ConcurrentModificationException_, and 
related _Iterator_: not applicable to SOLR Cache. 

Will never happen. We need to synchronize inserts because each insert may 
calculate size and remove 'eldest' entry, and we need to avoid OOMs. We need to 
synchronize retrieves for LRU because 'Linked' HashMap (with Access Order) will 
change links (will reorder Map). And we do not need to synchronize retrieves 
from Insertion-Ordered LinkedHashMap (FIFO). It is classic... i'd like to 
research more java.util.concurrent


> FIFO Cache (Unsynchronized): 9x times performance boost
> -------------------------------------------------------
>
>                 Key: SOLR-665
>                 URL: https://issues.apache.org/jira/browse/SOLR-665
>             Project: Solr
>          Issue Type: Improvement
>    Affects Versions: 1.3
>         Environment: JRockit R27 (Java 6)
>            Reporter: Fuad Efendi
>         Attachments: FIFOCache.java
>
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> Attached is modified version of LRUCache where 
> 1. map = new LinkedHashMap(initialSize, 0.75f, false) - so that 
> "reordering"/true (performance bottleneck of LRU) is replaced to 
> "insertion-order"/false (so that it became FIFO)
> 2. Almost all (absolutely unneccessary) synchronized statements commented out
> See discussion at 
> http://www.nabble.com/LRUCache---synchronized%21--td16439831.html
> Performance metrics (taken from SOLR Admin):
> LRU
> Requests: 7638
> Average Time-Per-Request: 15300
> Average Request-per-Second: 0.06
> FIFO:
> Requests: 3355
> Average Time-Per-Request: 1610
> Average Request-per-Second: 0.11
> Performance increased 9 times which roughly corresponds to a number of CPU in 
> a system, http://www.tokenizer.org/ (Shopping Search Engine at Tokenizer.org)
> Current number of documents: 7494689
> name:          filterCache  
> class:        org.apache.solr.search.LRUCache  
> version:      1.0  
> description:  LRU Cache(maxSize=10000000, initialSize=1000)  
> stats:        lookups : 15966954582
> hits : 16391851546
> hitratio : 0.102
> inserts : 4246120
> evictions : 0
> size : 2668705
> cumulative_lookups : 16415839763
> cumulative_hits : 16411608101
> cumulative_hitratio : 0.99
> cumulative_inserts : 4246246
> cumulative_evictions : 0 
> Thanks

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to