On 5/25/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
Since auditing solrconfig.xml defaults is on the list of things for 1.2, I thought I'd get the ball rolling:
Thanks, that was one of the things I was looking into now (hitting all the new URLs and seeing what they looked like too)
Lazy field loading: seems like it would benefit more people to be enabled explicitly. I've been using it successfully and some substantial gains have been reported on the lucene list. The downsides don't really seen significant.
Sounds fine.
HashDocSet maxSize: perhaps consider increasing this, or making this by default a parameter which is tuned automatically (.5% of maxDocs, for instance)
I think when HashDocSet is large enough, it can be slower than OpenBitSet for taking intersections, even when it still saves memory. So it depends on what one is optimizing for. I picked 3000 long ago since that it seemed the fastest for faceting with one particular data set (between 500K to 1M docs), but that was before OpenBitSet. It also caps the max table size at 4096 entries (16K RAM) (power of two hash table with a load factor of .75). Does it make sense to go up to 8K entries? Do you have any data on different sizes?
Most people will start with the example solrconfig.xml, I suspect, and getting the performance-related settings right at the start will help the perception of Solr's performance. I'd be tempted to increase the default filterCache size too, but that can have quite high memory requirements.
Yeah, many people won't think to increase the VM heap size. Perhaps that's better as a documentation fix. What about commenting out most of the default parameters in the dismax handler config, so it becomes more standard & usable (w/o editing it's config) after someone customizes their schema? -Yonik
