Well, it depends (tm). Raw search time should be unaffected (or very close to that). The stored data is in a completely separate file in the index directory and is not referenced during searches.
That said, assembling the response may take longer since you're potentially reading more data from the disk to create each document. Insure that lazy field loading is turned on, and when you're comparing times it would probably be best to return the same fields (perhaps just ID). Note that the Qtime in the response packet is the search, exclusive of assembling the response so that's probably a good number to measure. Best Erick On Fri, Jul 8, 2011 at 8:01 AM, jame vaalet <jamevaa...@gmail.com> wrote: > i would prefer every setting to be in its default stage and compare the > result with stored = true and False . > > 2011/7/8 François Schiettecatte <fschietteca...@gmail.com> > >> Hi >> >> I don't think that anyone has run such benchmarks, in fact this topic came >> up two weeks ago and I volunteered some time to do that because I have some >> spare time this week, so I am going to run some benchmarks this weekend and >> report back. >> >> The machine I have to do this a core i7 960, 24GB, 4TB of disk. I am going >> to run SOLR 3.3 under Tomcat 7.0.16. I have three databases I can use for >> this, icwsm-2009 (38.5GB compressed), cdip (24GB compressed), trec vlc2 >> (31GB compressed). I could also use a copy of wikipedia. I have lots of user >> searches I can use (saved from Feedster days). >> >> I would like some input on a couple of things to make this test as >> real-world as possible. One is any optimizations I should set in >> solrconfig.xml, and the other are the heap/GC settings I should set for >> tomcat. Anything else? >> >> Cheers >> >> François >> >> On Jul 8, 2011, at 4:08 AM, jame vaalet wrote: >> >> > hi, >> > >> > is there any performance degradation (response time etc ) if the index >> has >> > document content text stored in it (stored=true)? >> > >> > -JAME >> >> > > > -- > > -JAME >
