[
https://issues.apache.org/jira/browse/SOLR-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617441#action_12617441
]
Fuad Efendi commented on SOLR-665:
----------------------------------
Regarding Thread Safety:
- yes, we need synchronized get() method for LRU cache because each access
_reorders_ LinkedHashMap.
- absolutely no need to synchronize get() method for FIFO!
- probably we need to deal with insertion, but do not synchronize it: instead,
extend LinkedHashMap and make some 'removal' synchronized... With caches large
enough to store all object we do not need it. We probably do not need to
synchronize 'removal' at all - it removes entry but does not remove/finalize
referenced object.
>From JavaDoc: "Note that this implementation is not synchronized. If multiple
>threads access a linked hash map concurrently, and at least
one of the threads modifies the map structurally, it must be synchronized
externally."
However, we do not modify cache structurally during iteration loop or any other
'structure' access (we do not use Iterator!) - so, advice from JavaDoc is not
applicable.
We should synchronize only removeEntryForKey of HashMap; unfortunately we can't
do it without rewriting HashMap. Probably we can use ConcurrentHashMap as a
base class of LinkedHashMap, but I don't know answer yet... I am guessing that
unsynchronized entry removal won't be significant issue in multithreaded
environment.
> 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.
