Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
MIME-Version: 1.0
In-Reply-To: <dc85ed81c3a14de287e9170df7636cf1@MERCMBX44D.na.SAS.com>
References: <dc85ed81c3a14de287e9170df7636cf1@MERCMBX44D.na.SAS.com>
From: Chetan Mehrotra <chetan.mehrotra@gmail.com>
Date: Tue, 29 Aug 2017 22:03:04 -0700
Message-ID: <CAHCW-mksYoK3gbiQwX6Z-n=ffSjsJV6Xjfb9oZ_53xrO0E49EQ@mail.gmail.com>
Subject: Re: slowness accessing lucene results
To: users@jackrabbit.apache.org
Content-Type: text/plain; charset="UTF-8"
archived-at: Wed, 30 Aug 2017 05:03:12 -0000

The query can be slow due to multiple reasons

1. Copy-On-Write support is not enabled

2. Some of the JCR query constraints may not be getting mapped to
Lucene index i.e. index definition does not have full coverage of
query constraints causing quite a few paths to get filtered out. So
actual number of rows accessed may be large but only few of them
qualify all criteria at query engine level. This can be confirmed by
query explanation output

3. Or lots of filtering happening due to access control. Does the
performance remains same with admin user?

Chetan Mehrotra


On Mon, Aug 28, 2017 at 10:02 AM, Jason Bailey <Jason.Bailey@sas.com> wrote:
> Hi all,
>
> I'm tracking down a problem I'm currently experiencing when my queries use the lucene index on oak 1.2.18.  Here are the figures that I get from the acs commons tool that breaks down queries.
>
> "executeTime": 0
> "getNodesTime": 3279
> "count": 2949
> "countTime": 349807
> "totalTime": 353086
>
> In essence, it's taking me about 6 minutes to iterate through less than 3000 results. Does anyone have any ideas on root cause?
>
> -Jason