[ 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/30/08 10:08 AM: ------------------------------------------------------------ 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} - SOLR-669 http://issues.apache.org/jira/browse/SOLR-669 bq. 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. - sorry, I didn't understand... yes, if cache contains 100000 entries and 'most popular item' is removed... Why 'traverse all the other entries before getting that item'? why 99999 items are less popular (cumulative) than single one (absolute)? You probably mean 'LinkedList traversal' but this is not the case. This is why we need to browse JavaSource... LinkedHashMap extends HashMap and there is no any 'traversal', {code} public V get(Object key) { Entry<K,V> e = (Entry<K,V>)getEntry(key); if (e == null) return null; e.recordAccess(this); return e.value; } {code} 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! bq. 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. *What?!!* 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. 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} https://issues.apache.org/jira/browse/SOLR-669 bq. 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. - sorry, I didn't understand... yes, if cache contains 100000 entries and 'most popular item' is removed... Why 'traverse all the other entries before getting that item'? why 99999 items are less popular (cumulative) than single one (absolute)? You probably mean 'LinkedList traversal' but this is not the case. This is why we need to browse JavaSource... LinkedHashMap extends HashMap and there is no any 'traversal', {code} public V get(Object key) { Entry<K,V> e = (Entry<K,V>)getEntry(key); if (e == null) return null; e.recordAccess(this); return e.value; } {code} 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! bq. 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. *What?!!* 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: ConcurrentFIFOCache.java, ConcurrentFIFOCache.java, > ConcurrentLRUCache.java, ConcurrentLRUWeakCache.java, FIFOCache.java, > SimplestConcurrentLRUCache.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.