Return-Path: X-Original-To: apmail-lucene-solr-user-archive@minotaur.apache.org Delivered-To: apmail-lucene-solr-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3A01618E8A for ; Thu, 6 Aug 2015 12:35:37 +0000 (UTC) Received: (qmail 16241 invoked by uid 500); 6 Aug 2015 12:35:32 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 16176 invoked by uid 500); 6 Aug 2015 12:35:32 -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 16163 invoked by uid 99); 6 Aug 2015 12:35:31 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Aug 2015 12:35:31 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 6F01BC027F for ; Thu, 6 Aug 2015 12:35:31 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, KAM_COUK=1.1] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=messagingengine.com Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id kJ_SAsguMFAX for ; Thu, 6 Aug 2015 12:35:30 +0000 (UTC) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTPS id 09C9942AFB for ; Thu, 6 Aug 2015 12:35:29 +0000 (UTC) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 90FA120339 for ; Thu, 6 Aug 2015 08:33:22 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Thu, 06 Aug 2015 08:33:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=B6Wz04w4ZnoeLGh Ma5lMCQd3Pw0=; b=SvpiIY8akSX79Kry8RcvqNv85BoekkcQfXsaAu7lelX2Bis /AYTFzuJ2NpHrjaRxx6IHQwgJ90Ka7wHJixaSd5AMpkXOrfVq6Hesw8dpHoCD1x8 /na+MpIaU1Tlcva+9zH63+ZgSXDHgz67iOJMv22kszOlKJsONEWHl5t0EiTM= Received: by web6.nyi.internal (Postfix, from userid 99) id 62BEE573C4; Thu, 6 Aug 2015 08:33:22 -0400 (EDT) Message-Id: <1438864402.342925.349350361.506F47AE@webmail.messagingengine.com> X-Sasl-Enc: NecN1GsMx1a3VYkd46eTi2j8VTl54xT0l5ZnvgIORe5p 1438864402 From: Upayavira To: solr-user@lucene.apache.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-b53d9180 In-Reply-To: <1438861080.21228.11.camel@te-prime> References: <55C33E5F.6070304@uni-bielefeld.de> <1438861080.21228.11.camel@te-prime> Subject: Re: are facets or MatchAllDocsQuery not cached? Date: Thu, 06 Aug 2015 13:33:22 +0100 Typically such performance issues with faceting are to do with the time spend uninverting the index before calculating the facet counts. If you indexed the fields with docValues enabled, perhaps you could then use them for faceting, which might improve performance. If you are using a non-docValues field, and the second query is faster, then you could add the query to your static warming, look for newSearcher in your solrconfig.xml. That will execute your query, warming the caches used by faceting, before a new searcher is made available for searches. Upayavira On Thu, Aug 6, 2015, at 12:38 PM, Toke Eskildsen wrote: > On Thu, 2015-08-06 at 13:00 +0200, Bernd Fehling wrote: > > Single Index Solr 4.10.4, optimized Index, 76M docs, 235GB index size. > > > > I was analysing my solr logs and it turned out that I have some queries > > which are above 30 seconds qtime while normally the qtime is below 1 second. > > Looking closer about the queries it turned out that this is for MatchAllDocsQuery(*:*). > > Next was to turn debugQuery on and see where the bottleneck is. > > The result was that the facetting is consuming most of the qtime. > > > > So the question is, are facets or is facetting not cached? > > As far as I know it is not. 35 seconds for a match-all faceting sounds > fairly on par with what we are seeing (250M docs, 900GB shard). > > Of course response time is very depending on the field itself. If you > have very few unique values in your facet field(s), you might try > facet.method=enum. If that is not the case, your best bet would probably > be to cache the match-all outside of Solr. > > > My assumption is that the queryResultCache is catching such a MatchAllDocsQuery(*:*). > > It only stores the docIDs. > > I don't know why there is is no all_parameters -> complete_response > cache in Solr. > > - Toke Eskildsen, State and University Library, Denmark > >