Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <25757007.post@talk.nabble.com>
References: <25704607.post@talk.nabble.com> <25716499.post@talk.nabble.com>
	 <697f8380910020740y182300fbl7b8b800891c2ccf3@mail.gmail.com>
	 <25720351.post@talk.nabble.com> <25757007.post@talk.nabble.com>
Date: Tue, 6 Oct 2009 10:22:14 +0200
Message-ID: <697f8380910060122r1ca5ddfr254b7ba95677387e@mail.gmail.com>
Subject: Re: Date Property Performance in 1.6
From: Ard Schrijvers <a.schrijvers@onehippo.com>
To: users@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Oct 5, 2009 at 10:38 PM, majohnst <matt@lattaoutdoors.com> wrote:
>
> I've done a lot more digging and the slowdown seems to happen in the
> SortedLuceneQueryHits class. Specifically in the first two lines of the
> getHits() method. Line one creates a TopFieldDocCollector and line 2
> searches the index with searcher.search(query, collector).

has this code changed wrt the jackrabbit version for which is was
faster? If not, then what are the lucene versions in both cases?

>
> Since the query is trying to find a date that is >=, does this get turned
> into a range query in lucene? Would that slow things down?

Well, range queries are indeed slow. But, they shouldn't become slower
overnight. There are more effective ways in lucene these days, but
that is something for coming versions.

Regards Ard

>
>
>
> majohnst wrote:
>>
>> I am using the ObjectContentManager to run my queries, so I am not able to
>> set the setLimit(1). I also thought that since I have an order by clause,
>> the order by clause would override anything the respect document order
>> property does.
>>
>> The code for my query is:
>>
>> ObjectContentManager manager ... (injected from parent)
>> String finalQuery = "//element(*,my:namespace)[@property='value' and
>> @datestart<=xs:dateTime('2009-09-24T11:53:23.293-05:00')] order by
>> @datestart descending"
>> ObjectIterator iter = (ObjectIterator)
>> manager.getObjectIterator(finalQuery, Query.XPATH);
>>
>> I then iterate over the ObjectIterator to grab the first result. Normally
>> I would use iter.skip() to jump to a particular page in the search results
>> and begin iterating from there.
>>
>>
>> The ObjectContentManager.getObjectIterator() ends up calling
>> getNodeIterator(). In getNodeIterator(), the code is:
>>
>> Query jcrQuery =
>> session.getWorkspace().getQueryManager().createQuery(query, language);
>> QueryResult queryResult = jcrQuery.execute();
>> NodeIterator nodeIterator = queryResult.getNodes();
>> return nodeIterator;
>>
>>
>> By stepping through the process, I can see that the major bottleneck
>> happens in the NodeIterator for the line:
>> QueryResult queryResult = jcrQuery.execute();
>>
>>
>> So I really think that is has something to do with the query and not the
>> other parts of the process. Plus, when the date field is not present in
>> the query, the iterations and other methods all work fine without a
>> problem.
>>
>>
>>
>> Ard Schrijvers-3 wrote:
>>>
>>> <snip/>
>>>
>>>> In both the 1.5 and 1.6 sequential test, I only saw a minor performance
>>>> improvement in query time from query #1 to #2. But queries #2 to #20 all
>>>> had
>>>> the same query times. I am assuming that all the caching has warmed up
>>>> after
>>>> the first query.
>>>
>>> How many nodes are you querying? Did you try the setLimit(1), because
>>> then we know whether it is really the query that is slower.
>>> Furthermore, you do not have respectDocumentOrder set to true, as I
>>> think the response is so slow. OTOH, it might be that you are
>>> retrieving all the search results, so, you are in that case not
>>> testing the search but also the authorization of the nodes (or do you
>>> also iterate over the search results?).
>>>
>>> Regards Ard
>>>
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Date-Property-Performance-in-1.6-tp25704607p25757007.html
> Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
>
>