Return-Path: Delivered-To: apmail-lucene-solr-user-archive@minotaur.apache.org Received: (qmail 95275 invoked from network); 1 Apr 2010 01:14:03 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Apr 2010 01:14:03 -0000 Received: (qmail 27499 invoked by uid 500); 1 Apr 2010 01:14:00 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 27437 invoked by uid 500); 1 Apr 2010 01:14:00 -0000 Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-user@lucene.apache.org Delivered-To: mailing list solr-user@lucene.apache.org Received: (qmail 27427 invoked by uid 99); 1 Apr 2010 01:14:00 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Apr 2010 01:14:00 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [208.69.42.181] (HELO radix.cryptio.net) (208.69.42.181) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Apr 2010 01:13:53 +0000 Received: by radix.cryptio.net (Postfix, from userid 1007) id C156771C2AE; Wed, 31 Mar 2010 18:13:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by radix.cryptio.net (Postfix) with ESMTP id BF45171C1E3 for ; Wed, 31 Mar 2010 18:13:31 -0700 (PDT) Date: Wed, 31 Mar 2010 18:13:31 -0700 (PDT) From: Chris Hostetter To: solr-user@lucene.apache.org Subject: Re: resetting stats In-Reply-To: Message-ID: References: <4BA888BC.1020004@gmail.com> <25ac6c851003301921k408e1300xf8df46f61b13643d@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Checked: Checked by ClamAV on apache.org : 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