lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fuad Efendi (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (SOLR-665) FIFO Cache (Unsynchronized): 9x times performance boost
Date Tue, 29 Jul 2008 03:46:31 GMT

    [ 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:46 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. 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!

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}

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)?


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.


Mime
View raw message