That high of a difference is due to the part of the index containing these particular stored fields not being in OS cache. What's the size on disk of your index compared to your physical RAM?
-Yonik On Mon, Jul 28, 2008 at 4:10 PM, Britske <[EMAIL PROTECTED]> wrote: > > Hi all, > > For some queries I need to return a lot of rows at once (say 100). > When performing these queries I notice a big difference between qTime (which > is mostly in the 15-30 ms range due to caching) and total time taken to > return the response (measured through SolrJ's elapsedTime), which takes > between 500-1600 ms. > > For queries which return less rows the difference becomes less big. > > I presume (after reading some threads in the past) that this is due to solr > constructing and streaming the response (which includes retrieving the > stored fields) , which is something that is not calculated in qTime. > > Documents have a lot of stored fields (more than 10.000), but at any given > query a maximum of say 20 are returned (through fl-field ) or used (as part > of filtering, faceting, sorting) > > I would have thought that enabling enableLazyFieldLoading for this situation > would mean a lot, since so many stored fields can be skipped, but I notice > no real difference in measuring total elapsed time (or qTime for that > matter). > > Am I missing something here? What criteria would need to be met for a field > to not be loaded for instance? Should I see a big performance boost in this > situation? > > Thanks, > Britske > -- > View this message in context: > http://www.nabble.com/big-discrepancy-between-elapsedtime-and-qtime-although-enableLazyFieldLoading%3D-true-tp18698590p18698590.html > Sent from the Solr - User mailing list archive at Nabble.com. > >
