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....@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....@gmail.com > >wrote: > > > If that is the case, what would help? > > > > > > On Thu, Mar 13, 2014 at 8:46 PM, Otis Gospodnetic < > > otis.gospodne...@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....@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.gospodne...@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.t...@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....@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 > >> > > > > > >> > > > > >> > > > >> > > >> > > > > >
