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: <c3ac3bad0910020252i18af08d3pfc64dcd5aa2a3441@mail.gmail.com>
References: <25704607.post@talk.nabble.com>
	 <c3ac3bad0910020252i18af08d3pfc64dcd5aa2a3441@mail.gmail.com>
Date: Fri, 2 Oct 2009 12:05:15 +0200
Message-ID: <697f8380910020305m5feb8b9du1881b38d7f2a556c@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 Fri, Oct 2, 2009 at 11:52 AM, Alexander Klimetschek <aklimets@day.com> wrote:
> On Thu, Oct 1, 2009 at 20:52, majohnst <matt@lattaoutdoors.com> wrote:
>> If I add a date property:
>> //element(*,my:namespace)[@property='value' and
>> @datestart<=xs:dateTime('2009-09-24T11:53:23.293-05:00')] order by
>> @datestart descending
>>
>> the results are:
>> 1.5 = 1.5 seconds
>> 1.6 = 3.5 seconds
>>
>> What changed in version 1.6 that would cause the date performance to degrade
>> so much?
>
> Are the query times still consistently slower when you ran the query
> multiple times and take the average?

1.5 seconds for a very simple query like:

 //element(*,my:namespace)[@property='value'] order by @datestart descending

is strange already. As Alexander points out, you need to test like 10
times the query, *after* you ran the query already 10 times. This is
in order to rule out FS caches warming up, lucene caches, etc etc.
Also, pls, use a setLimit(1) on the query (perhaps you first need to
cast to QueryImpl) to rule out the fetching of the nodes: this way,
you get a better idea *how* long the lucene part takes. Again, 1.5
seconds is very long, but might be reasonable for the very first time
you order on datestart as then all fieldcache's in lucene are still
empty.

Regards Ard

>
> Regards,
> Alex
>
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
>