[
https://issues.apache.org/jira/browse/SOLR-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617648#action_12617648
]
Lars Kotthoff commented on SOLR-665:
------------------------------------
bq. Not everything in JAVA is extremely good: for instance, synchronization.
Even for single-threaded application, it needs additionally 600 CPU cycles
(I've read it somewhere for SUN Java 1.3 on Windows)
That's probably not true for modern JVMs though -- cf.
http://www.ibm.com/developerworks/library/j-jtp04223.html.
bq. ...9x times performance boost...
How did you measure that exactly? The Solr admin pages will *not* give you
exact measurements. Could you describe the test setup in detail? I'm guessing
that you're caching the results of all queries in memory such that no disk
access is necessary. Are you using highlighting or anything else that might be
CPU-intensive at all? From my personal experience with Solr I wouldn't expect
synchronization for the caches to be that big of a performance penalty. In some
of my tests with a several GB index where all results where cached and
highlighting was turned on I've seen throughputs in excess of 400 searches per
second. I think that the performance bottleneck in this case was the network
interface for sending the replies.
bq. absolutely no need to synchronize get() method for FIFO!
Consider the following case: thread A performs a synchronized put, thread B
performs an unsynchronized get on the same key. B gets scheduled before A
completes, the returned value will be undefined. Yes, we could do sanity checks
to minimise these cases, but that would probably end up being more expensive
than the synchronization.
bq. 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."
That's exactly the case here -- the update thread modifies the map
structurally! It doesn't do this at all times, probably even never after the
cache has been populated, but there's no way to *know* for sure unless you
*explicitely* remove the put method.
I'm not convinced that we should change the current implementation for the
following reasons:
* Concurrency is traditionally a discipline which is very hard to get right.
Furthermore the serious bugs tend to show up only when you really get race
conditions and the like, i.e. when the machine is under heavy load and any
disruption will hit you seriously.
* You've already started to amend your implementation with sanity checks and
the like -- as I've said before, this might end up being more expensive than
synchronization.
* A FIFO cache might become a bottleneck itself -- if the cache is very large
and the most frequently accessed item is inserted just after the cache is
created, all accesses will need to traverse all the other entries before
getting that item.
That said, if you can show conclusively (e.g. with a profiler) that the
synchronized access is indeed the bottleneck and incurs a heavy penalty on
performance, then I'm all for investigating this further.
> 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.
