jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From majohnst <m...@lattaoutdoors.com>
Subject Re: Date Property Performance in 1.6
Date Mon, 05 Oct 2009 20:38:37 GMT

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).

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?



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.


Mime
View raw message