Dear Ard,
>>But, as in your example, the time takes doesn't say to much, because it
>>is not clear wether the time taken is in the lucene query or in the
>>getResults.
yes you are right Lucene query is not taking much time, it is after the
execution of query, when I try to loop through the resultset, it is taking
time to fetch the first node
below is snippet of code
QueryResult results = getQueryResults(query);
NodeIterator it = results.getNodes();
log.debug("Size is " + it.getSize());
BulletinDTO dto = null;
//while (it.hasNext()) {
for (int i= 0; i < it.getSize(); i++){
Node n = it.nextNode(); =====> this is where it is
taking more time for
fetch the first record. after that it is looping fast
Is there anything wrong with NodeIterator?
>> now, add ((QueryImpl)q).setLimit(1);
I try to use this technique to measure the performance, but I could not find
setLimit() method in QueryImpl. I tried both
org.apache.jackrabbit.core.query.lucene.QueryImpl and
org.apache.jackrabbit.core.query.QueryImpl.
Alternatively in repository.xml I have added a param 'resultFetchSize' set
to 1. to workspace SearchIndex.
<SearchIndex
class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
</SearchIndex>
</Workspace>
but still no improvement.
Thanks in advance
Ard Schrijvers wrote:
>
> Hello Kisu,
>
>> Kisu San wrote:
>>
>> My Xpath query is
>>
>> //element(*, "BULLETIN")[jcr:deref(@btnmodel= 'MODEL_NAME')
>> and jcr:deref(@btnbulletin_type= 'INFO')]
>>
>> BULLETIN ==> Node type
>> btnmodel = REFERENCE property in BULLETIN node
>> btnbulletin_type= REFERENCE property in BULLETIN node
>>
>> I have created 10,000 of the bulletin nodes, of which 1000
>> are matching to my search criteria. That means, returned
>> reasult set will have 1000 nodes.
>>
>> It is taking 319,012 milli seconds ~ 5.31 seconds on DB2 and
>> 246,157 milli seconds on Derby.
>>
>> Which is lot of time in my opinion.
>
> Yes, this is a lot of time. I haven't had yet time to look at jcr:deref
> (DerefQuery), so I am not sure wether this query might be slow.
> Currently, there are certain queries which might become slow, see for
> example https://issues.apache.org/jira/browse/JCR-1196.
>
> But, as in your example, the time takes doesn't say to much, because it
> is not clear wether the time taken is in the lucene query or in the
> getResults. Obviously, the first part, the lucene query is independant
> of your DB. Also, 300 ms - 5 sec is a big difference. But, you might
> refer to 5 sec the very first time you search, where all caches are
> empty, the lucene caches are empty, your FS cache is empty, the readers
> are yet read, etc etc
>
> So, I cannot do anything with the numbers you currently show. For 10.000
> nodes, even the slowest queries should be (pretty) fast. So, I propose
> you do the following:
>
> 1) Set the limit of results returned because you just shouldn't fetch
> 1000 nodes at once : you have something like:
> Query q =
> superuser.getWorkspace().getQueryManager().createQuery(........)
>
> now, add ((QueryImpl)q).setLimit(1);
>
> 2) Measure the time of the third (three times in row) 'result =
> q.execute();' , not the first.
>
> Now, change the ((QueryImpl)q).setLimit(1); to for example
> ((QueryImpl)q).setLimit(1000); and see the difference. Fetching 1000
> nodes in QueryResultImpl.getResults(long size) will obviously, certainly
> when you just started the repository like in a unittest which you
> probably are doing, always be slower
>
> Regards Ard
>
>>
>> Can any one tell me if there is anyway of improving performance??
>>
>> Thanks in Advance
>> Kishore
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Jackrabbit-XPath-performance-tf4765307.h
>> tml#a13629022
>> Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Jackrabbit-XPath-performance-tf4765307.html#a13651097
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
