Re: Solr-4663 - Alternatives to use same data dir in different cores for optimal cache performance
Maybe you're right. The problem is that with the different types of queries it is hard to properly size document- and queryResultCaches (one query requests 10 results per page, others up to 12000). We tried different approaches, cache sizes and spend hours with JVM configuration (OutOfMemory problems and lot of stop the world collections). Having multiple cores, on the other hand, would drastically increase indexing time. I'm just looking at possible ways to improve query performance without increasing indexing time (only full imports possible). Regards Dom 2013/7/27 Erick Erickson erickerick...@gmail.com You can certainly have multiple Solrs pointing to the same underlying physical index if (and only if) you absolutely guarantee that only one Solr will write to the index at a time. But I'm not sure this is premature optimization or not. Problem is that your multiple Solrs are eating up the same physical memory, so I'm not quite sure whether the fact that you have different query characteristics is best served by multiple cores or not. Have you measured improvements with your proposed architecture? Best Erick On Fri, Jul 26, 2013 at 3:23 AM, Dominik Siebel m...@dsiebel.de wrote: Hi, I just found SOLR-4663 beeing patched in the latest update I did. Does anyone know any other solution to use ONE physical index for various purposes? Why? I would like to use different solconfig.xmls in terms of cache sizes, result window size, etc. per business case for optimal performance, while relying on the same data. This is due to the fact the queries are mostly completely different in structure and result size and we only have one unified search index (indexing performance). Any suggestions (besides replicating the index to another core on the same machine, of course ;) )? Cheers! Dom
Re: Solr-4663 - Alternatives to use same data dir in different cores for optimal cache performance
Hi, Yes, it can be done, if you search the mailing list for 'two solr instances same datadir', you will a post where i am describing our setup - it works well even with automated deployments how do you measure performance? I am asking before one reason for us having the same setup is sharing the OS cache, i'd be curious to see your numbers and i can also (very soon) share ours. roman On Fri, Jul 26, 2013 at 3:23 AM, Dominik Siebel m...@dsiebel.de wrote: Hi, I just found SOLR-4663 beeing patched in the latest update I did. Does anyone know any other solution to use ONE physical index for various purposes? Why? I would like to use different solconfig.xmls in terms of cache sizes, result window size, etc. per business case for optimal performance, while relying on the same data. This is due to the fact the queries are mostly completely different in structure and result size and we only have one unified search index (indexing performance). Any suggestions (besides replicating the index to another core on the same machine, of course ;) )? Cheers! Dom
Re: Solr-4663 - Alternatives to use same data dir in different cores for optimal cache performance
You can certainly have multiple Solrs pointing to the same underlying physical index if (and only if) you absolutely guarantee that only one Solr will write to the index at a time. But I'm not sure this is premature optimization or not. Problem is that your multiple Solrs are eating up the same physical memory, so I'm not quite sure whether the fact that you have different query characteristics is best served by multiple cores or not. Have you measured improvements with your proposed architecture? Best Erick On Fri, Jul 26, 2013 at 3:23 AM, Dominik Siebel m...@dsiebel.de wrote: Hi, I just found SOLR-4663 beeing patched in the latest update I did. Does anyone know any other solution to use ONE physical index for various purposes? Why? I would like to use different solconfig.xmls in terms of cache sizes, result window size, etc. per business case for optimal performance, while relying on the same data. This is due to the fact the queries are mostly completely different in structure and result size and we only have one unified search index (indexing performance). Any suggestions (besides replicating the index to another core on the same machine, of course ;) )? Cheers! Dom
