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 >
