lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Britske <gbr...@gmail.com>
Subject Re: big perf-difference between solr-server vs. SOlrJ req.process(solrserver)
Date Mon, 31 Dec 2007 13:58:04 GMT

I imagine then that this "scanning-cost" is proportional to the number of
stored fields, correct? 

I tested this with generating a second index with 1/10th of the
product-variants (and thus 1/10th) of the stored fields. However I really
don't see the expected (at least by me) drop in post-processing time (which
includes lazy loading the needed fields and scanning all the stored fields).

Moreover, I realized that I'm using an xsl-transform in the post-processing
phase. This would contribute to the high cost I'm seeing as well I think.
Can this XSL-transform in general be considered small in relation to the
abovementioned costs?

Thanks, 
Geert-Jan 


Yonik Seeley wrote:
> 
> On Dec 27, 2007 11:01 AM, Britske <gbrits@gmail.com> wrote:
>> after inspecting solrconfig.xml I see that I already have enabled lazy
>> field
>> loading by:
>> <enableLazyFieldLoading>true</enableLazyFieldLoading> (I guess it was
>> enabled by default)
>>
>> Since any query returns about 10 fields (which differ from query to
>> query) ,
>> would this mean that only these 10 of about 2000-4000 fields are
>> retrieved /
>> loaded?
> 
> Yes, but that's not the whole story.
> Lucene stores all of the fields back-to-back with no index (there is
> no random access to particular stored fields)... so all of the fields
> must be at least scanned.
> 
> -Yonik
> 
> 

-- 
View this message in context: http://www.nabble.com/big-perf-difference-between-solr-server-vs.--SOlrJ-req.process%28solrserver%29-tp14513964p14557779.html
Sent from the Solr - User mailing list archive at Nabble.com.


Mime
View raw message