[
https://issues.apache.org/jira/browse/SOLR-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617654#action_12617654
]
funtick edited comment on SOLR-665 at 7/28/08 8:36 PM:
-----------------------------------------------------------
bq. The Solr admin pages will not give you exact measurements.
Yes, and I do not need exact measurements! It gives me averageTimePerRequest
which improved almost 10 times on production server. Should I right JUnit tests
and execute it in a single-threaded environment? Better is to use The Grinder,
but I don't have time and spare CPUs.
bq. I've seen throughputs in excess of 400 searches per second.
But 'searches per second' is not the same as 'average response time'!!!
bq. Are you using highlighting or anything else that might be CPU-intensive at
all?
Yes, I am using highlighting. You can see it at http://www.tokenizer.org
bq. I'm guessing that you're caching the results of all queries in memory such
that no disk access is necessary.
{color:red} But this is another bug of SOLR!!! I am using extremely large
caches but SOLR still *recalculates* facet intersections. {color}
bq. 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.
the returned value is well defined: it is either null or correct value.
bq. That's exactly the case here - the update thread modifies the map
structurally!
Who cares? We are not iterating the map!
Anyway, I believe simplified ConcurrentLRU backed by ConcurrentHashMap is
easier to understand and troubleshoot...
bq. I don't see the point of the static popularityCounter... that looks like a
bug.
No, it is not a bug. it is virtually "checkpoint", like as a timer, one timer
for all instances. We can use System.currentTimeMillis() instead, but static
volatile long is faster.
About specific use case: yes... if someone has 0.5 seconds response time for
faceted queries I am very happy... I had 15 seconds before going with FIFO.
was (Author: funtick):
bq. The Solr admin pages will not give you exact measurements.
Yes, and I do not need exact measurements! It gives me averageTimePerRequest
which improved almost 10 times on production server. Should I right JUnit tests
and execute it in a single-threaded environment? Better is to use The Grinder,
but I don't have time and spare CPUs.
bq. 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.
the returned value is well defined: it is either null or correct value.
bq. That's exactly the case here - the update thread modifies the map
structurally!
Who cares? We are not iterating the map!
Anyway, I believe simplified ConcurrentLRU backed by ConcurrentHashMap is
easier to understand and troubleshoot...
bq. I don't see the point of the static popularityCounter... that looks like a
bug.
No, it is not a bug. it is virtually "checkpoint", like as a timer, one timer
for all instances. We can use System.currentTimeMillis() instead, but static
volatile long is faster.
About specific use case: yes... if someone has 0.5 seconds response time for
faceted queries I am very happy... I had 15 seconds before going with FIFO.
> 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.
