>I didn't see where you said what Solr version you were using. below is the solr version info :- Solr Specification Version: 1.2.2008.07.22.15.48.39 Solr Implementation Version: 1.3-dev Lucene Specification Version: 2.3.1 Lucene Implementation Version: 2.3.1 629191 - buschmi - 2008-02-19 19:15:48
>this can happen with really big indexes that can't all fit in memory one of our index is pretty big its about 16 GB , other indexes are small (for other applications ) our servers have 32 GB ram >There are some pretty big concurrency differences between 1.3 and 1.4 too (if >your tests involve many concurrent requests). as I said we observed latency in our live(production) system that is when we started logging response at the client to identify the problem , so in our live (production) system there is considerable concurrency during peak times On 11/3/09, Yonik Seeley <yo...@lucidimagination.com> wrote: > On Mon, Nov 2, 2009 at 2:21 PM, bharath venkatesh > <bharathv6.proj...@gmail.com> wrote: >> we observed many times there is huge mismatch between qtime and >> time measured at the client for the response > > Long times to stream back the result to the client could be due to > - client not reading fast enough > - network congestion > - reading the stored fields takes a long time > - this can happen with really big indexes that can't all fit in > memory, and stored fields tend to not be cached well by the OS > (essentially random access patterns over a huge area). This ends up > causing a disk seek per document being > streamed back. > - locking contention for reading the index (under Solr 1.3, but not > under 1.4 on non-windows platforms) > > I didn't see where you said what Solr version you were using. There > are some pretty big concurrency differences between 1.3 and 1.4 too > (if your tests involve many concurrent requests). > > -Yonik > http://www.lucidimagination.com >
