[prev in list] [next in list] [prev in thread] [next in thread] 

List:       solr-user
Subject:    Re: resetting stats
From:       Ian Connor <ian.connor () gmail ! com>
Date:       2011-01-31 16:46:21
Message-ID: AANLkTikOQYqWdyTmJ0KXSUFe2=39E+BzTP89TcvR7xfj () mail ! gmail ! com
[Download RAW message or body]


Has there been any progress on this or tools people might use to capture the
average or 90% time for the last hour?

That would allow us to better match up slowness with other metrics like
CPU/IO/Memory to find bottlenecks in the system.

Thanks,
Ian.

On Wed, Mar 31, 2010 at 9:13 PM, Chris Hostetter
<hossman_lucene@fucit.org>wrote:

>
> : Say I have 3 Cores names core0, core1, and core2, where only core1 and
> core2
> : have documents and caches.  If all my searches hit core0, and core0
> shards
> : out to core1 and core2, then the stats from core0 would be accurate for
> : errors, timeouts, totalTime, avgTimePerRequest, avgRequestsPerSecond,
> etc.
>
> Ahhh.... yes. (i see what you mean by "aggregating core" now ... i thought
> you ment a core just for aggregatign stats)
>
> *If* you are using distributed search, then you can gather stats from the
> core you use for collating/aggregating from the other shards, and
> reloading that core should be cheap.
>
> but if you aren't already using distributed searching, it would be a bad
> idea from a performance standpoint to add it just to take advantage of
> being able to reload the coordinator core (the overhead of searching one
> distributed shard vs doing the same query directly is usually very
> measurable, even on if the shard is the same Solr instance as your
> coordinator)
>
>
>
> -Hoss
>
>


-- 
Regards,

Ian Connor
1 Leighton St #723
Cambridge, MA 02141
Call Center Phone: +1 (714) 239 3875 (24 hrs)
Fax: +1(770) 818 5697
Skype: ian.connor


[prev in list] [next in list] [prev in thread] [next in thread]