Try to resend email. I would appreciate if someone could answer the questions posed in this email
Thank you Savvas ---------- Forwarded message ---------- From: Savas Triantafillou <[EMAIL PROTECTED]> Date: Feb 10, 2007 1:48 AM Subject: Jackrabbit query performance issues To: [email protected], [email protected] Hi all, I would like to point out two issues concerning query function and performance The repository against which the following queries run, contained only 500 nodes, all versionable, 340 of which were of node type required by the queries The purpose is to find the most suitable form for a query to be efficient and fast 1. As you may see in the following queries, I would like to load all nodes of a certain type using several forms The first one provides no information about the root path of the nodes, nor any information about their name DEBUG - QueryImpl.execute(149) | executed in 0,26 s. (//element(*, my:object)) The second one provides information about the node's name and is already slower than the first one, considering that it executed immediately after the first query (i.e. cache seemed not to be working) and that it is slightly more specific than the first one DEBUG - QueryImpl.execute(149) | executed in 0,36 s. (//element(objectName, my:object)) The third query is similar to first one except the presence of the ordering. Is the difference in time justified only by the presence of the ordering ? DEBUG - QueryImpl.execute(149) | executed in 1,03 s. (//element(*, my:object) order by @modified descending) The fourth query is similar to the second one with the addition of the orerding. Taking into account query execution times so far this time seems the most rational DEBUG - QueryImpl.execute(149) | executed in 0,58 s. (//element(objectName, my:object) order by @modified descending) The fifth query is more specific concerning the path of the nodes. It seems that cache seems to be working now DEBUG - QueryImpl.execute(149) | executed in 0,12 s. (/jcr:root/my:system/my:objectRoot//element(*, my:object)) The sixth query is even more specific, yet it is slower than the above one!!!! DEBUG - QueryImpl.execute(149) | executed in 0,25 s. (/jcr:root/my:system/my:objectRoot//element(objectName, my:object)) The last two queries differ in the presence of the ordering DEBUG - QueryImpl.execute(149) | executed in 0,62 s. (/jcr:root/my:system/my:objectRoot/objectNameTypeFolder//element(*, my:object) order by @modified descending) DEBUG - QueryImpl.execute(149) | executed in 0,14 s. (/jcr:root/my:system/my:objectRoot/objectNameTypeFolder//element(objectName, my:object) order by @modified descending) Now, in order to have a more complete view, I have changed the order of the queries in that more specific queries are executed first. Here are the results DEBUG - QueryImpl.execute(149) | executed in 0,55 s. (/jcr:root/my:system/my:objectRoot//element(*, my:object)) DEBUG - QueryImpl.execute(149) | executed in 0,44 s. (/jcr:root/my:system/my:objectRoot//element(objectName, my:object)) DEBUG - QueryImpl.execute(149) | executed in 1,36 s. (/jcr:root/my:system/my:objectRoot/objectNameTypeFolder//element(*, my:object) order by @modified descending) DEBUG - QueryImpl.execute(149) | executed in 0,16 s. (/jcr:root/my:system/my:objectRoot/objectNameTypeFolder//element(objectName, my:object) order by @modified descending) DEBUG - QueryImpl.execute(149) | executed in 0,03 s. (//element(*, my:object)) DEBUG - QueryImpl.execute(149) | executed in 0,30 s. (//element(objectName, my:object)) DEBUG - QueryImpl.execute(149) | executed in 0,28 s. (//element(*, my:object) order by @modified descending) DEBUG - QueryImpl.execute(149) | executed in 0,11 s. (//element(objectName, my:object) order by @modified descending) My belief is that there is no specific rule for creating a query that will guarantee a satisfactory time, not even the most obvious one, i.e. the more specific the query is, the faster it becomes. 2. For each one of the 340 nodes I have created 40 versions and then rerun the above queries. All times tripled which makes me think that a query of type //element(*, my:nodeType) will make Jackrabbit search through its version nodes as well. If this is the case, why this is happening? I would really appreciate your thoughts as we are using Jackrabbit as a backend to a portal and migration from 1.1.1 to 1.2.1 changed portal performance dramatically. Therefore understanding of how Jackrabbit functions in respect to queries is crucial Thank you for your time, Savvas
