jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Savas Triantafillou" <savvas.triantafil...@gmail.com>
Subject Fwd: Jackrabbit query performance issues
Date Sun, 11 Feb 2007 11:17:19 GMT
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 <savvas.triantafillou@gmail.com>
Date: Feb 10, 2007 1:48 AM
Subject: Jackrabbit query performance issues
To: dev@jackrabbit.apache.org, users@jackrabbit.apache.org

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message