You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Software Dev <st...@gmail.com> on 2014/03/13 20:18:26 UTC
Help me understand these newrelic graphs
Here are some screen shots of our Solr Cloud cluster via Newrelic
http://postimg.org/gallery/2hyzyeyc/
We currently have a 5 node cluster and all indexing is done on separate
machines and shipped over. Our machines are running on SSD's with 18G of
ram (Index size is 8G). We only have 1 shard at the moment with replicas on
all 5 machines. I'm guessing thats a bit of a waste?
How come when we do our bulk updating the response time actually decreases?
I would think the load would be higher therefor response time should be
higher. Any way I can decrease the response time?
Thanks
Re: Help me understand these newrelic graphs
Posted by Software Dev <st...@gmail.com>.
Otis, I want to get those spikes down lower if possible. As mentioned in
the above posts that the 25ms timing you are seeing is not really accurate
because that's the average response time for ALL requests including the
bulk add operations which are generally super fast. Our true response time
is around 100ms.
On Fri, Mar 14, 2014 at 10:54 AM, Otis Gospodnetic <
otis.gospodnetic@gmail.com> wrote:
> Are you trying to bring that 24.9 ms response time down?
> Looks like there is room for more aggressive sharing there, yes.
>
> Otis
> --
> Performance Monitoring * Log Analytics * Search Analytics
> Solr & Elasticsearch Support * http://sematext.com/
>
>
> On Fri, Mar 14, 2014 at 1:07 PM, Software Dev <static.void.dev@gmail.com
> >wrote:
>
> > Here is a screenshot of the host information:
> > http://postimg.org/image/vub5ihxix/
> >
> > As you can see we have 24 core CPU's and the load is only at 5-7.5.
> >
> >
> > On Fri, Mar 14, 2014 at 10:02 AM, Software Dev <
> static.void.dev@gmail.com
> > >wrote:
> >
> > > If that is the case, what would help?
> > >
> > >
> > > On Thu, Mar 13, 2014 at 8:46 PM, Otis Gospodnetic <
> > > otis.gospodnetic@gmail.com> wrote:
> > >
> > >> It really depends, hard to give a definitive instruction without more
> > >> pieces of info.
> > >> e.g. if your CPUs are all maxed out and you already have a high number
> > of
> > >> concurrent queries than sharding may not be of any help at all.
> > >>
> > >> Otis
> > >> --
> > >> Performance Monitoring * Log Analytics * Search Analytics
> > >> Solr & Elasticsearch Support * http://sematext.com/
> > >>
> > >>
> > >> On Thu, Mar 13, 2014 at 7:42 PM, Software Dev <
> > static.void.dev@gmail.com
> > >> >wrote:
> > >>
> > >> > Ahh.. its including the add operation. That makes sense I then. A
> bit
> > >> silly
> > >> > on NR's part they don't break it down.
> > >> >
> > >> > Otis, our index is only 8G so I don't consider that big by any means
> > but
> > >> > our queries can get a bit complex with a bit of faceting. Do you
> still
> > >> > think it makes sense to shard? How easy would this be to get
> working?
> > >> >
> > >> >
> > >> > On Thu, Mar 13, 2014 at 4:02 PM, Otis Gospodnetic <
> > >> > otis.gospodnetic@gmail.com> wrote:
> > >> >
> > >> > > Hi,
> > >> > >
> > >> > > I think NR has support for breaking by handler, no? Just checked
> -
> > >> no.
> > >> > > Only webapp controller, but that doesn't apply to Solr.
> > >> > >
> > >> > > SPM should be more helpful when it comes to monitoring Solr - you
> > can
> > >> > > filter by host, handler, collection/core, etc. -- you can see the
> > >> demo -
> > >> > > https://apps.sematext.com/demo - though this is plain Solr, not
> > >> > SolrCloud.
> > >> > >
> > >> > > If your index is big or queries are complex, shard it and
> > parallelize
> > >> > > search.
> > >> > >
> > >> > > Otis
> > >> > > --
> > >> > > Performance Monitoring * Log Analytics * Search Analytics
> > >> > > Solr & Elasticsearch Support * http://sematext.com/
> > >> > >
> > >> > >
> > >> > > On Thu, Mar 13, 2014 at 6:17 PM, ralph tice <ralph.tice@gmail.com
> >
> > >> > wrote:
> > >> > >
> > >> > > > I think your response time is including the average response for
> > an
> > >> add
> > >> > > > operation, which generally returns very quickly and due to sheer
> > >> number
> > >> > > are
> > >> > > > averaging out the response time of your queries. New Relic
> should
> > >> > break
> > >> > > > out requests based on which handler they're hitting but they
> don't
> > >> seem
> > >> > > to.
> > >> > > >
> > >> > > >
> > >> > > > On Thu, Mar 13, 2014 at 2:18 PM, Software Dev <
> > >> > static.void.dev@gmail.com
> > >> > > > >wrote:
> > >> > > >
> > >> > > > > Here are some screen shots of our Solr Cloud cluster via
> > Newrelic
> > >> > > > >
> > >> > > > > http://postimg.org/gallery/2hyzyeyc/
> > >> > > > >
> > >> > > > > We currently have a 5 node cluster and all indexing is done on
> > >> > separate
> > >> > > > > machines and shipped over. Our machines are running on SSD's
> > with
> > >> 18G
> > >> > > of
> > >> > > > > ram (Index size is 8G). We only have 1 shard at the moment
> with
> > >> > > replicas
> > >> > > > on
> > >> > > > > all 5 machines. I'm guessing thats a bit of a waste?
> > >> > > > >
> > >> > > > > How come when we do our bulk updating the response time
> actually
> > >> > > > decreases?
> > >> > > > > I would think the load would be higher therefor response time
> > >> should
> > >> > be
> > >> > > > > higher. Any way I can decrease the response time?
> > >> > > > >
> > >> > > > > Thanks
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: Help me understand these newrelic graphs
Posted by Otis Gospodnetic <ot...@gmail.com>.
Are you trying to bring that 24.9 ms response time down?
Looks like there is room for more aggressive sharing there, yes.
Otis
--
Performance Monitoring * Log Analytics * Search Analytics
Solr & Elasticsearch Support * http://sematext.com/
On Fri, Mar 14, 2014 at 1:07 PM, Software Dev <st...@gmail.com>wrote:
> Here is a screenshot of the host information:
> http://postimg.org/image/vub5ihxix/
>
> As you can see we have 24 core CPU's and the load is only at 5-7.5.
>
>
> On Fri, Mar 14, 2014 at 10:02 AM, Software Dev <static.void.dev@gmail.com
> >wrote:
>
> > If that is the case, what would help?
> >
> >
> > On Thu, Mar 13, 2014 at 8:46 PM, Otis Gospodnetic <
> > otis.gospodnetic@gmail.com> wrote:
> >
> >> It really depends, hard to give a definitive instruction without more
> >> pieces of info.
> >> e.g. if your CPUs are all maxed out and you already have a high number
> of
> >> concurrent queries than sharding may not be of any help at all.
> >>
> >> Otis
> >> --
> >> Performance Monitoring * Log Analytics * Search Analytics
> >> Solr & Elasticsearch Support * http://sematext.com/
> >>
> >>
> >> On Thu, Mar 13, 2014 at 7:42 PM, Software Dev <
> static.void.dev@gmail.com
> >> >wrote:
> >>
> >> > Ahh.. its including the add operation. That makes sense I then. A bit
> >> silly
> >> > on NR's part they don't break it down.
> >> >
> >> > Otis, our index is only 8G so I don't consider that big by any means
> but
> >> > our queries can get a bit complex with a bit of faceting. Do you still
> >> > think it makes sense to shard? How easy would this be to get working?
> >> >
> >> >
> >> > On Thu, Mar 13, 2014 at 4:02 PM, Otis Gospodnetic <
> >> > otis.gospodnetic@gmail.com> wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > I think NR has support for breaking by handler, no? Just checked -
> >> no.
> >> > > Only webapp controller, but that doesn't apply to Solr.
> >> > >
> >> > > SPM should be more helpful when it comes to monitoring Solr - you
> can
> >> > > filter by host, handler, collection/core, etc. -- you can see the
> >> demo -
> >> > > https://apps.sematext.com/demo - though this is plain Solr, not
> >> > SolrCloud.
> >> > >
> >> > > If your index is big or queries are complex, shard it and
> parallelize
> >> > > search.
> >> > >
> >> > > Otis
> >> > > --
> >> > > Performance Monitoring * Log Analytics * Search Analytics
> >> > > Solr & Elasticsearch Support * http://sematext.com/
> >> > >
> >> > >
> >> > > On Thu, Mar 13, 2014 at 6:17 PM, ralph tice <ra...@gmail.com>
> >> > wrote:
> >> > >
> >> > > > I think your response time is including the average response for
> an
> >> add
> >> > > > operation, which generally returns very quickly and due to sheer
> >> number
> >> > > are
> >> > > > averaging out the response time of your queries. New Relic should
> >> > break
> >> > > > out requests based on which handler they're hitting but they don't
> >> seem
> >> > > to.
> >> > > >
> >> > > >
> >> > > > On Thu, Mar 13, 2014 at 2:18 PM, Software Dev <
> >> > static.void.dev@gmail.com
> >> > > > >wrote:
> >> > > >
> >> > > > > Here are some screen shots of our Solr Cloud cluster via
> Newrelic
> >> > > > >
> >> > > > > http://postimg.org/gallery/2hyzyeyc/
> >> > > > >
> >> > > > > We currently have a 5 node cluster and all indexing is done on
> >> > separate
> >> > > > > machines and shipped over. Our machines are running on SSD's
> with
> >> 18G
> >> > > of
> >> > > > > ram (Index size is 8G). We only have 1 shard at the moment with
> >> > > replicas
> >> > > > on
> >> > > > > all 5 machines. I'm guessing thats a bit of a waste?
> >> > > > >
> >> > > > > How come when we do our bulk updating the response time actually
> >> > > > decreases?
> >> > > > > I would think the load would be higher therefor response time
> >> should
> >> > be
> >> > > > > higher. Any way I can decrease the response time?
> >> > > > >
> >> > > > > Thanks
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: Help me understand these newrelic graphs
Posted by Software Dev <st...@gmail.com>.
Here is a screenshot of the host information:
http://postimg.org/image/vub5ihxix/
As you can see we have 24 core CPU's and the load is only at 5-7.5.
On Fri, Mar 14, 2014 at 10:02 AM, Software Dev <st...@gmail.com>wrote:
> If that is the case, what would help?
>
>
> On Thu, Mar 13, 2014 at 8:46 PM, Otis Gospodnetic <
> otis.gospodnetic@gmail.com> wrote:
>
>> It really depends, hard to give a definitive instruction without more
>> pieces of info.
>> e.g. if your CPUs are all maxed out and you already have a high number of
>> concurrent queries than sharding may not be of any help at all.
>>
>> Otis
>> --
>> Performance Monitoring * Log Analytics * Search Analytics
>> Solr & Elasticsearch Support * http://sematext.com/
>>
>>
>> On Thu, Mar 13, 2014 at 7:42 PM, Software Dev <static.void.dev@gmail.com
>> >wrote:
>>
>> > Ahh.. its including the add operation. That makes sense I then. A bit
>> silly
>> > on NR's part they don't break it down.
>> >
>> > Otis, our index is only 8G so I don't consider that big by any means but
>> > our queries can get a bit complex with a bit of faceting. Do you still
>> > think it makes sense to shard? How easy would this be to get working?
>> >
>> >
>> > On Thu, Mar 13, 2014 at 4:02 PM, Otis Gospodnetic <
>> > otis.gospodnetic@gmail.com> wrote:
>> >
>> > > Hi,
>> > >
>> > > I think NR has support for breaking by handler, no? Just checked -
>> no.
>> > > Only webapp controller, but that doesn't apply to Solr.
>> > >
>> > > SPM should be more helpful when it comes to monitoring Solr - you can
>> > > filter by host, handler, collection/core, etc. -- you can see the
>> demo -
>> > > https://apps.sematext.com/demo - though this is plain Solr, not
>> > SolrCloud.
>> > >
>> > > If your index is big or queries are complex, shard it and parallelize
>> > > search.
>> > >
>> > > Otis
>> > > --
>> > > Performance Monitoring * Log Analytics * Search Analytics
>> > > Solr & Elasticsearch Support * http://sematext.com/
>> > >
>> > >
>> > > On Thu, Mar 13, 2014 at 6:17 PM, ralph tice <ra...@gmail.com>
>> > wrote:
>> > >
>> > > > I think your response time is including the average response for an
>> add
>> > > > operation, which generally returns very quickly and due to sheer
>> number
>> > > are
>> > > > averaging out the response time of your queries. New Relic should
>> > break
>> > > > out requests based on which handler they're hitting but they don't
>> seem
>> > > to.
>> > > >
>> > > >
>> > > > On Thu, Mar 13, 2014 at 2:18 PM, Software Dev <
>> > static.void.dev@gmail.com
>> > > > >wrote:
>> > > >
>> > > > > Here are some screen shots of our Solr Cloud cluster via Newrelic
>> > > > >
>> > > > > http://postimg.org/gallery/2hyzyeyc/
>> > > > >
>> > > > > We currently have a 5 node cluster and all indexing is done on
>> > separate
>> > > > > machines and shipped over. Our machines are running on SSD's with
>> 18G
>> > > of
>> > > > > ram (Index size is 8G). We only have 1 shard at the moment with
>> > > replicas
>> > > > on
>> > > > > all 5 machines. I'm guessing thats a bit of a waste?
>> > > > >
>> > > > > How come when we do our bulk updating the response time actually
>> > > > decreases?
>> > > > > I would think the load would be higher therefor response time
>> should
>> > be
>> > > > > higher. Any way I can decrease the response time?
>> > > > >
>> > > > > Thanks
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: Help me understand these newrelic graphs
Posted by Software Dev <st...@gmail.com>.
If that is the case, what would help?
On Thu, Mar 13, 2014 at 8:46 PM, Otis Gospodnetic <
otis.gospodnetic@gmail.com> wrote:
> It really depends, hard to give a definitive instruction without more
> pieces of info.
> e.g. if your CPUs are all maxed out and you already have a high number of
> concurrent queries than sharding may not be of any help at all.
>
> Otis
> --
> Performance Monitoring * Log Analytics * Search Analytics
> Solr & Elasticsearch Support * http://sematext.com/
>
>
> On Thu, Mar 13, 2014 at 7:42 PM, Software Dev <static.void.dev@gmail.com
> >wrote:
>
> > Ahh.. its including the add operation. That makes sense I then. A bit
> silly
> > on NR's part they don't break it down.
> >
> > Otis, our index is only 8G so I don't consider that big by any means but
> > our queries can get a bit complex with a bit of faceting. Do you still
> > think it makes sense to shard? How easy would this be to get working?
> >
> >
> > On Thu, Mar 13, 2014 at 4:02 PM, Otis Gospodnetic <
> > otis.gospodnetic@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I think NR has support for breaking by handler, no? Just checked - no.
> > > Only webapp controller, but that doesn't apply to Solr.
> > >
> > > SPM should be more helpful when it comes to monitoring Solr - you can
> > > filter by host, handler, collection/core, etc. -- you can see the demo
> -
> > > https://apps.sematext.com/demo - though this is plain Solr, not
> > SolrCloud.
> > >
> > > If your index is big or queries are complex, shard it and parallelize
> > > search.
> > >
> > > Otis
> > > --
> > > Performance Monitoring * Log Analytics * Search Analytics
> > > Solr & Elasticsearch Support * http://sematext.com/
> > >
> > >
> > > On Thu, Mar 13, 2014 at 6:17 PM, ralph tice <ra...@gmail.com>
> > wrote:
> > >
> > > > I think your response time is including the average response for an
> add
> > > > operation, which generally returns very quickly and due to sheer
> number
> > > are
> > > > averaging out the response time of your queries. New Relic should
> > break
> > > > out requests based on which handler they're hitting but they don't
> seem
> > > to.
> > > >
> > > >
> > > > On Thu, Mar 13, 2014 at 2:18 PM, Software Dev <
> > static.void.dev@gmail.com
> > > > >wrote:
> > > >
> > > > > Here are some screen shots of our Solr Cloud cluster via Newrelic
> > > > >
> > > > > http://postimg.org/gallery/2hyzyeyc/
> > > > >
> > > > > We currently have a 5 node cluster and all indexing is done on
> > separate
> > > > > machines and shipped over. Our machines are running on SSD's with
> 18G
> > > of
> > > > > ram (Index size is 8G). We only have 1 shard at the moment with
> > > replicas
> > > > on
> > > > > all 5 machines. I'm guessing thats a bit of a waste?
> > > > >
> > > > > How come when we do our bulk updating the response time actually
> > > > decreases?
> > > > > I would think the load would be higher therefor response time
> should
> > be
> > > > > higher. Any way I can decrease the response time?
> > > > >
> > > > > Thanks
> > > > >
> > > >
> > >
> >
>
Re: Help me understand these newrelic graphs
Posted by Otis Gospodnetic <ot...@gmail.com>.
It really depends, hard to give a definitive instruction without more
pieces of info.
e.g. if your CPUs are all maxed out and you already have a high number of
concurrent queries than sharding may not be of any help at all.
Otis
--
Performance Monitoring * Log Analytics * Search Analytics
Solr & Elasticsearch Support * http://sematext.com/
On Thu, Mar 13, 2014 at 7:42 PM, Software Dev <st...@gmail.com>wrote:
> Ahh.. its including the add operation. That makes sense I then. A bit silly
> on NR's part they don't break it down.
>
> Otis, our index is only 8G so I don't consider that big by any means but
> our queries can get a bit complex with a bit of faceting. Do you still
> think it makes sense to shard? How easy would this be to get working?
>
>
> On Thu, Mar 13, 2014 at 4:02 PM, Otis Gospodnetic <
> otis.gospodnetic@gmail.com> wrote:
>
> > Hi,
> >
> > I think NR has support for breaking by handler, no? Just checked - no.
> > Only webapp controller, but that doesn't apply to Solr.
> >
> > SPM should be more helpful when it comes to monitoring Solr - you can
> > filter by host, handler, collection/core, etc. -- you can see the demo -
> > https://apps.sematext.com/demo - though this is plain Solr, not
> SolrCloud.
> >
> > If your index is big or queries are complex, shard it and parallelize
> > search.
> >
> > Otis
> > --
> > Performance Monitoring * Log Analytics * Search Analytics
> > Solr & Elasticsearch Support * http://sematext.com/
> >
> >
> > On Thu, Mar 13, 2014 at 6:17 PM, ralph tice <ra...@gmail.com>
> wrote:
> >
> > > I think your response time is including the average response for an add
> > > operation, which generally returns very quickly and due to sheer number
> > are
> > > averaging out the response time of your queries. New Relic should
> break
> > > out requests based on which handler they're hitting but they don't seem
> > to.
> > >
> > >
> > > On Thu, Mar 13, 2014 at 2:18 PM, Software Dev <
> static.void.dev@gmail.com
> > > >wrote:
> > >
> > > > Here are some screen shots of our Solr Cloud cluster via Newrelic
> > > >
> > > > http://postimg.org/gallery/2hyzyeyc/
> > > >
> > > > We currently have a 5 node cluster and all indexing is done on
> separate
> > > > machines and shipped over. Our machines are running on SSD's with 18G
> > of
> > > > ram (Index size is 8G). We only have 1 shard at the moment with
> > replicas
> > > on
> > > > all 5 machines. I'm guessing thats a bit of a waste?
> > > >
> > > > How come when we do our bulk updating the response time actually
> > > decreases?
> > > > I would think the load would be higher therefor response time should
> be
> > > > higher. Any way I can decrease the response time?
> > > >
> > > > Thanks
> > > >
> > >
> >
>
Re: Help me understand these newrelic graphs
Posted by Software Dev <st...@gmail.com>.
Ahh.. its including the add operation. That makes sense I then. A bit silly
on NR's part they don't break it down.
Otis, our index is only 8G so I don't consider that big by any means but
our queries can get a bit complex with a bit of faceting. Do you still
think it makes sense to shard? How easy would this be to get working?
On Thu, Mar 13, 2014 at 4:02 PM, Otis Gospodnetic <
otis.gospodnetic@gmail.com> wrote:
> Hi,
>
> I think NR has support for breaking by handler, no? Just checked - no.
> Only webapp controller, but that doesn't apply to Solr.
>
> SPM should be more helpful when it comes to monitoring Solr - you can
> filter by host, handler, collection/core, etc. -- you can see the demo -
> https://apps.sematext.com/demo - though this is plain Solr, not SolrCloud.
>
> If your index is big or queries are complex, shard it and parallelize
> search.
>
> Otis
> --
> Performance Monitoring * Log Analytics * Search Analytics
> Solr & Elasticsearch Support * http://sematext.com/
>
>
> On Thu, Mar 13, 2014 at 6:17 PM, ralph tice <ra...@gmail.com> wrote:
>
> > I think your response time is including the average response for an add
> > operation, which generally returns very quickly and due to sheer number
> are
> > averaging out the response time of your queries. New Relic should break
> > out requests based on which handler they're hitting but they don't seem
> to.
> >
> >
> > On Thu, Mar 13, 2014 at 2:18 PM, Software Dev <static.void.dev@gmail.com
> > >wrote:
> >
> > > Here are some screen shots of our Solr Cloud cluster via Newrelic
> > >
> > > http://postimg.org/gallery/2hyzyeyc/
> > >
> > > We currently have a 5 node cluster and all indexing is done on separate
> > > machines and shipped over. Our machines are running on SSD's with 18G
> of
> > > ram (Index size is 8G). We only have 1 shard at the moment with
> replicas
> > on
> > > all 5 machines. I'm guessing thats a bit of a waste?
> > >
> > > How come when we do our bulk updating the response time actually
> > decreases?
> > > I would think the load would be higher therefor response time should be
> > > higher. Any way I can decrease the response time?
> > >
> > > Thanks
> > >
> >
>
Re: Help me understand these newrelic graphs
Posted by Otis Gospodnetic <ot...@gmail.com>.
Hi,
I think NR has support for breaking by handler, no? Just checked - no.
Only webapp controller, but that doesn't apply to Solr.
SPM should be more helpful when it comes to monitoring Solr - you can
filter by host, handler, collection/core, etc. -- you can see the demo -
https://apps.sematext.com/demo - though this is plain Solr, not SolrCloud.
If your index is big or queries are complex, shard it and parallelize
search.
Otis
--
Performance Monitoring * Log Analytics * Search Analytics
Solr & Elasticsearch Support * http://sematext.com/
On Thu, Mar 13, 2014 at 6:17 PM, ralph tice <ra...@gmail.com> wrote:
> I think your response time is including the average response for an add
> operation, which generally returns very quickly and due to sheer number are
> averaging out the response time of your queries. New Relic should break
> out requests based on which handler they're hitting but they don't seem to.
>
>
> On Thu, Mar 13, 2014 at 2:18 PM, Software Dev <static.void.dev@gmail.com
> >wrote:
>
> > Here are some screen shots of our Solr Cloud cluster via Newrelic
> >
> > http://postimg.org/gallery/2hyzyeyc/
> >
> > We currently have a 5 node cluster and all indexing is done on separate
> > machines and shipped over. Our machines are running on SSD's with 18G of
> > ram (Index size is 8G). We only have 1 shard at the moment with replicas
> on
> > all 5 machines. I'm guessing thats a bit of a waste?
> >
> > How come when we do our bulk updating the response time actually
> decreases?
> > I would think the load would be higher therefor response time should be
> > higher. Any way I can decrease the response time?
> >
> > Thanks
> >
>
Re: Help me understand these newrelic graphs
Posted by Ahmet Arslan <io...@yahoo.com>.
Hi,
Ralphs comment makes sense. We can confirm his explanation. What happens when you select only QueryComponent and FacetComponent in first graph (requests response time)?
On Friday, March 14, 2014 12:18 AM, ralph tice <ra...@gmail.com> wrote:
I think your response time is including the average response for an add
operation, which generally returns very quickly and due to sheer number are
averaging out the response time of your queries. New Relic should break
out requests based on which handler they're hitting but they don't seem to.
On Thu, Mar 13, 2014 at 2:18 PM, Software Dev <st...@gmail.com>wrote:
> Here are some screen shots of our Solr Cloud cluster via Newrelic
>
> http://postimg.org/gallery/2hyzyeyc/
>
> We currently have a 5 node cluster and all indexing is done on separate
> machines and shipped over. Our machines are running on SSD's with 18G of
> ram (Index size is 8G). We only have 1 shard at the moment with replicas on
> all 5 machines. I'm guessing thats a bit of a waste?
>
> How come when we do our bulk updating the response time actually decreases?
> I would think the load would be higher therefor response time should be
> higher. Any way I can decrease the response time?
>
> Thanks
>
Re: Help me understand these newrelic graphs
Posted by ralph tice <ra...@gmail.com>.
I think your response time is including the average response for an add
operation, which generally returns very quickly and due to sheer number are
averaging out the response time of your queries. New Relic should break
out requests based on which handler they're hitting but they don't seem to.
On Thu, Mar 13, 2014 at 2:18 PM, Software Dev <st...@gmail.com>wrote:
> Here are some screen shots of our Solr Cloud cluster via Newrelic
>
> http://postimg.org/gallery/2hyzyeyc/
>
> We currently have a 5 node cluster and all indexing is done on separate
> machines and shipped over. Our machines are running on SSD's with 18G of
> ram (Index size is 8G). We only have 1 shard at the moment with replicas on
> all 5 machines. I'm guessing thats a bit of a waste?
>
> How come when we do our bulk updating the response time actually decreases?
> I would think the load would be higher therefor response time should be
> higher. Any way I can decrease the response time?
>
> Thanks
>