[ 
https://issues.apache.org/jira/browse/SOLR-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yonik Seeley updated SOLR-667:
------------------------------

    Attachment: SOLR-667-alternate.patch

OK, here's the implementation based on my previous pseudo code, along with a 
very quick performance test.
The test uses random keys over a slightly bigger range than the table.
It also uses an upper water mark 10% higher than the lower water mark, and an 
acceptable water mark half way inbetween.  I haven't experimented to see what 
the best acceptable water mark is for either impl.  If anyone wants to do a 
more realistic test with real queries, they are welcome to it.

I did 4 runs and took the lowest number for each sub-test.  Java6 -server, 
WinXP, P4.  Times in milliseconds.
{code}
    doPerfTest(2000000, 100000, 200000); // big cache
noble=17063  yonik=9157
    doPerfTest(2000000, 100000, 120000);  // smaller key space increases 
distance between 
oldest, newest and makes the first passes less effective.
noble=8391  yonik=5812
    doPerfTest(6000000, 1000, 2000);    // small cache, smaller hit rate
noble=17578  yonik=12515
    doPerfTest(6000000, 1000, 1200);    // small cache, bigger hit rate
noble=11500  yonik=8219
{code}


> Alternate LRUCache implementation
> ---------------------------------
>
>                 Key: SOLR-667
>                 URL: https://issues.apache.org/jira/browse/SOLR-667
>             Project: Solr
>          Issue Type: New Feature
>          Components: search
>    Affects Versions: 1.3
>            Reporter: Noble Paul
>            Assignee: Yonik Seeley
>             Fix For: 1.4
>
>         Attachments: ConcurrentLRUCache.java, ConcurrentLRUCache.java, 
> ConcurrentLRUCache.java, SOLR-667-alternate.patch, SOLR-667-updates.patch, 
> SOLR-667.patch, SOLR-667.patch, SOLR-667.patch, SOLR-667.patch, 
> SOLR-667.patch, SOLR-667.patch, SOLR-667.patch, SOLR-667.patch, SOLR-667.patch
>
>
> The only available SolrCache i.e LRUCache is based on _LinkedHashMap_ which 
> has _get()_ also synchronized. This can cause severe bottlenecks for faceted 
> search. Any alternate implementation which can be faster/better must be 
> considered. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to