[
https://issues.apache.org/jira/browse/SOLR-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617684#action_12617684
]
funtick edited comment on SOLR-665 at 7/28/08 9:20 PM:
-----------------------------------------------------------
bq. Fuad is after fastest-possible reads, everybody is after reasonable
behavior in the face of concurrent writes
Thanks and sorry for runtime errors;
FIFO looks strange at first, but... for large cache (100000 items), most
popular item can be _mistakenly_ removed... but I don't think there are any
'most popular facets' etc.; it's evenly distributed in most cases.
Another issue: SOLR always tries _recalculate_ _facets_ even with extremely
large filterCache & queryResultCache, even the same faceted query shows always
the same long response times.
bq. It is if nothing is modifying the map during the get. If something is
modifying the map you don't know how the implementation handles the insert of a
new value. It might copy the object, and you'd end up with half an object or
even an invalid memory location. That's why the javadoc says that you must
synchronize accesses if anything modifies the map - this is not limited to
iterators.
I agree of course... However, we are not dealing with unknown implementation of
java.util.Map clonig (java.lang.Cloneable) objects somehow or using some weird
object introspection etc....
was (Author: funtick):
bq. Fuad is after fastest-possible reads, everybody is after reasonable
behavior in the face of concurrent writes
Thanks and sorry for runtime errors;
FIFO looks strange at first, but... for large cache (100000 items), most
popular item can be _mistakenly_ removed... but I don't think there are any
'most popular facets' etc.; it's evenly distributed in most cases.
Another issue: SOLR always tries _recalculate_ _facets_ even with extremely
large filterCache & queryResultCache, even the same faceted query shows always
the same long response times.
> 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.
