Return-Path: X-Original-To: apmail-lucene-java-user-archive@www.apache.org Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EF03E18C74 for ; Mon, 15 Jun 2015 08:57:20 +0000 (UTC) Received: (qmail 32804 invoked by uid 500); 15 Jun 2015 08:57:19 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 32750 invoked by uid 500); 15 Jun 2015 08:57:19 -0000 Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@lucene.apache.org Delivered-To: mailing list java-user@lucene.apache.org Received: (qmail 32736 invoked by uid 99); 15 Jun 2015 08:57:19 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 15 Jun 2015 08:57:19 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of profondometer@gmail.com designates 209.85.213.43 as permitted sender) Received: from [209.85.213.43] (HELO mail-yh0-f43.google.com) (209.85.213.43) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 15 Jun 2015 08:55:03 +0000 Received: by yhid80 with SMTP id d80so38299717yhi.1 for ; Mon, 15 Jun 2015 01:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WCI/j7eKispEdDugm/IXj2wIbW4Czp8RkolLjg4BOP8=; b=NRmPIwR7T6ccvgwHeOigakxJnbfITIc9U+J65d+D5ppy48S/8lO60hDTEyMznuJ9W1 XC/ZxNx7JgRxEFi30xQZdjFUw8vTxLShdPJpwD55yyec+c42sQrvT2AMhnBAaQn/ax9V aXQxd9Qo8BJYy5VJUg9iFzvQiUaLIB2Vlt03DW0H0DM3O5HGvaTolEz5NoE0DLPmmW56 oQDTGMiJ1NaE3G8pyPYFkhvPMtK+CdexlqDx1gkHgws+Nm3gZmAqmVU22clJhnETivzi TffU8XxGsrKZ2Ti3KdOaP4rixSO0UOra8RTZ5lFVvgpaC77clKaSEnc8Rp1VYNb8VjzX onzQ== MIME-Version: 1.0 X-Received: by 10.13.217.147 with SMTP id b141mr33473371ywe.22.1434358611273; Mon, 15 Jun 2015 01:56:51 -0700 (PDT) Received: by 10.13.213.11 with HTTP; Mon, 15 Jun 2015 01:56:51 -0700 (PDT) Date: Mon, 15 Jun 2015 11:56:51 +0300 Message-ID: Subject: CachingWrapperQuery performance From: Anton Lyska To: java-user@lucene.apache.org Content-Type: multipart/alternative; boundary=001a114fd9aa816d1d05188aa36c X-Virus-Checked: Checked by ClamAV on apache.org --001a114fd9aa816d1d05188aa36c Content-Type: text/plain; charset=UTF-8 Hi, I have performance issues with CachingWrapperQuery with lucene 5.2 and dont know how to solve it. Prehistory: I have search with different parameters, where some parameters are used more frequently then others. For these params I used filters(and cached them), and my search looked like this BooleanFilter bf = new BooleanFilter (); bf.add(.., BooleanClause.Occur.MUST); //frequently used params here bf.add(.., BooleanClause.Occur.MUST); Filter searchFilter = new CachingWrapperFilter(bf); //and this filter object was reused between queries BooleanQuery searchQuery = new BooleanQuery(); searchQuery.add(.., BooleanClause.Occur.MUST); searchQuery.add(.., BooleanClause.Occur.MUST); hits = searcher.search(searchQuery, searchFilter, count, sort); And everything were great. I looked at two popular queries and each took 32 ms and 22 ms to execute. Now I did upgrade Lucene to 5.2 (from 5.0), and saw that filters are deprecated and its advisable to use queries and CachingWrapperQuery. So i changed sources to this: BooleanQuery bq = new BooleanQuery (); //now it becomes BooleanQuery bq.add(.., BooleanClause.Occur.MUST); //frequently used params here, same terms as before bq.add(.., BooleanClause.Occur.MUST); Query cachedQuery = new CachingWrapperQuery(bq); //this object is reused between queries BooleanQuery searchQuery = new BooleanQuery(); searchQuery.add(.., BooleanClause.Occur.MUST); searchQuery.add(.., BooleanClause.Occur.MUST); searchQuery.add(cachedQuery, BooleanClause.Occur.FILTER); //here i add cached part of the query hits = searcher.search(searchQuery, count, sort); Later I looked at same queries, and they took 145ms and 95ms to execute! Moving to CachingWrapperQuery was the only difference between queries, so question is: How to use CachingWrapperQuery right in my situation, or should I switch back to filters? --001a114fd9aa816d1d05188aa36c--