lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: Advise on an architecture with lot of cores
Date Tue, 07 Oct 2014 14:01:36 GMT
"On the other hand,
it [sic] most of the cores are idle most of the time, the 1 core/customer
setup would be give better utilization of the hardware."

This is an important point.  I've seen performance go to hell when 10M, 100M, and 1B cloud
collections were consolidated in a hardware constrained environment.  The data belonged to
the same customer and there were good reason for this approach.  In our case, we were able
to reduce our queries by n-1 (where n is the number of collections consolidated), but the
overall query was slower; many seconds vs subsecond.  You won't have that option, but maybe
you are in a better place wrt hardware. The newer cloud routing may also play an important
role here (maybe someone else could speak to that).  As you alluded earlier, the query generation
must be altered to generate a fq security clause (operator precedence is important here).

If search performance is a vital part of your company's service offering, then it's definitely
worth the money to collect representative queries and test on alternate hardware before committing
your production environment.



On October 7, 2014 8:56:46 AM EST, Manoj Bharadwaj <> wrote:
>Hi Toke,
>Thank you for your insights.
>> Why do you want to collapse the cores?
>Most of the cores are small and a few big ones make up the bulk. Our
>thinking was that it would be as easy to just have one core. Monitoring
>becomes easy as well (we are using a monitoring tool in which there is
>limit on the number of endpoints that can be monitored, and we are
>considering other monitoring solutions including Sematext).

Sent from my mobile. Please excuse my brevity.
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message