headers
Jean-Baptiste Quenot | 30 Mar 2006 09:56
Picon
Favicon

Document order enabled by default

Hello,

First,  thanks  a lot  for  providing  Jackrabbit.  I'm  currently
evaluating it for replacing an  XML database that is not providing
good enough response times.

I used Jackrabbit from the jcr block of Cocoon, imported thousands
of XML documents using the builtin XML import facility and started
to write  a query.  At first  glance, the response times  were not
what I was expecting at all  (40 seconds), as I heard queries were
based on Lucene.

So after digging/debugging into the  code I noticed Jackrabbit was
spending an  awful lot of  time in Arrays.sort(), and  appeared to
use DocOrderNodeIteratorImpl as implementation of NodeIterator.

So I watched the source for lucene.QueryImpl and noticed the use
of a default implicit order on the search results:

    /**
     * If <code>true</code> the default ordering of the result nodes is in
     * document order.
     */
    private boolean documentOrder = true;

After switching  off this attribute with  an ugly hack in  my code
and a patch to QueryImpl, search results dropped to a few hundreds
milliseconds.

Is there  an easy way  to configure this setting?   Maybe pointing
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Perez | 30 Mar 2006 10:04
Picon
Gravatar

Re: Document order enabled by default

Sure:
    <SearchIndex>
        .....
        <param name="respectDocumentOrder" value="false"/>
    </SearchIndex>

By default the value is true.

Martin

On 3/30/06, Jean-Baptiste Quenot <jbq <at> apache.org> wrote:
>
> Hello,
>
> First,  thanks  a lot  for  providing  Jackrabbit.  I'm  currently
> evaluating it for replacing an  XML database that is not providing
> good enough response times.
>
> I used Jackrabbit from the jcr block of Cocoon, imported thousands
> of XML documents using the builtin XML import facility and started
> to write  a query.  At first  glance, the response times  were not
> what I was expecting at all  (40 seconds), as I heard queries were
> based on Lucene.
>
> So after digging/debugging into the  code I noticed Jackrabbit was
> spending an  awful lot of  time in Arrays.sort(), and  appeared to
> use DocOrderNodeIteratorImpl as implementation of NodeIterator.
>
> So I watched the source for lucene.QueryImpl and noticed the use
> of a default implicit order on the search results:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jean-Baptiste Quenot | 30 Mar 2006 10:17
Picon
Favicon

Looking for benchmarks and references

Hello,

It  appears  that  the   mailing-list  archives  were  moved  upon
graduation  from the  incubator.   I'm looking  for benchmarks  to
« sell » this technology and to show that jackrabbit is scalable.

Can  you  please  point   me  to  relevant  information  regarding
scalability and  performance?  Also if I  could mention references
and big names, that would help a lot.

TIA,
--

-- 
Jean-Baptiste Quenot
http://caraldi.com/jbq/
Permalink | Reply | 4 comments |
headers
samiam | 30 Mar 2006 10:29

persistence manager and file systems


hello there

i have two questions about the ObjectPersistenceManager and two about the
file systems. at http://jackrabbit.apache.org/faq.html are some points i am
not sure about yet.
i) one contra against the ObjectPersistenceManager is described as "if the
JVM process is killed the repository might turn inconsistent". what does
this exactly mean?

ii) is the ObjectPersistenceManager depending on the CQFS file system?

iii) one contra against LocalFileSystem is "slow on windows boxes" and one
contra against DbFileSystem is "slower than native file systems". does this
mean, that Db is slower than LocalFileSystem or is it really about a naive
file system?

iv) are there any useful links about the CQFS file system? i googled but was
not able to find helpful information (for example licensing)

i would appreciate any help
greetings
sam
--
View this message in context: http://www.nabble.com/persistence-manager-and-file-systems-t1367151.html#a3666080
Sent from the Jackrabbit - Users forum at Nabble.com.
Permalink | Reply | 3 comments |
headers
Martin Perez | 30 Mar 2006 12:59
Picon
Gravatar

Re: persistence manager and file systems

Not an expert, but I will try to answer as good as I can. Maybe an expert
can give you best answers.

i) one contra against the ObjectPersistenceManager is described as "if the
> JVM process is killed the repository might turn inconsistent". what does
> this exactly mean?

Probably because the objects are stored on memory and flushed on
session.save() calls or maybe on regular intervals. If you kill the VM, you
can kill the process in the middle of a save/flush operation.

ii) is the ObjectPersistenceManager depending on the CQFS file system?

No. As far as I know persistence managers and file systems are independent.

iii) one contra against LocalFileSystem is "slow on windows boxes" and one
> contra against DbFileSystem is "slower than native file systems". does
> this
> mean, that Db is slower than LocalFileSystem or is it really about a naive
> file system?

If they say that a database file system is slow than native file systems
then it should be slower than LocalFileSystem.

iv) are there any useful links about the CQFS file system? i googled but was
> not able to find helpful information (for example licensing)

As far as I know this is a propietary file system developed by day software,
so you cannot use it on open source projects.
(Continue reading)

Permalink | Reply | 2 comments |
headers
samiam | 30 Mar 2006 14:26

Re: persistence manager and file systems


is there any information about the performance benefit of CQFS in contrast to
DbFileSystem or LocalFileSystem? under which circumstances (number of nodes,
filesize of binary content, ...) is the CQFS a real performance improvement
to the repository?

tx
sam
--
View this message in context: http://www.nabble.com/persistence-manager-and-file-systems-t1367151.html#a3668993
Sent from the Jackrabbit - Users forum at Nabble.com.
Permalink | Reply | 1 comment |
headers
Marcel Reutegger | 30 Mar 2006 14:36
Picon

Re: persistence manager and file systems

samiam wrote:
> is there any information about the performance benefit of CQFS in contrast to
> DbFileSystem or LocalFileSystem? under which circumstances (number of nodes,
> filesize of binary content, ...) is the CQFS a real performance improvement
> to the repository?

there was a thread about performance some time ago, see:

http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/566

regards
  marcel
Permalink | Reply | 0 comments |
headers
Jean-Baptiste Quenot | 30 Mar 2006 14:58
Picon
Favicon

Re: Looking for benchmarks and references

* Jean-Baptiste Quenot:
> 
> It  appears  that  the   mailing-list  archives  were  moved  upon
> graduation  from the  incubator.

Seems to be available on gmane: http://news.gmane.org/gmane.comp.apache.jackrabbit.devel

BTW I have found a JMeter-based benchmark tool in
contrib/jcr-commands/jmeter-chain that I can use to do the
benchmark myself ;-)
--

-- 
Jean-Baptiste Quenot
http://caraldi.com/jbq/
Permalink | Reply | 3 comments |
headers
samiam | 30 Mar 2006 15:28

Re: Looking for benchmarks and references


would you provide the results of your benchmarks here?
--
View this message in context: http://www.nabble.com/Looking-for-benchmarks-and-references-t1367099.html#a3669876
Sent from the Jackrabbit - Users forum at Nabble.com.
Permalink | Reply | 0 comments |
headers
Jean-Baptiste Quenot | 30 Mar 2006 17:26
Picon
Favicon

Re: Looking for benchmarks and references

* Jean-Baptiste Quenot:

> BTW I have found a JMeter-based benchmark tool in
> contrib/jcr-commands/jmeter-chain that I can use to do the
> benchmark myself ;-)

I need help to have the jmeter benchmark tool running.  Here's
what I've done:

1)  checkout jackrabbit
2)  cd trunk/jackrabbit
3)  maven
4)  ../contrib/jcr-commands/jmeter-chain
5)  fetch JMeter libs by hand and put them in ~/.maven as they
    don't appear in the apache repo
6)  cp ../maven.xml . ; maven
    Note that maven.xml is missing in jmeter-chain
7)  cd .. ; maven
8)  Copy built libs to jmeter/lib/ext:
    jcr-commands-1.0-SNAPSHOT.jar
    jmeter-chain-1.0-dev.jar
9)  Copy dependencies to jmeter/lib:
    commons-jelly-20030902.160215.jar
    commons-jelly-20030902.160215.jar.md5
    commons-jelly-tags-xml-20040613.030723.jar
    commons-jelly-tags-velocity-20030303.205659.jar.md5
    commons-jelly-tags-velocity-20030303.205659.jar
    commons-jelly-tags-log-20030211.142821.jar.md5
    commons-jelly-tags-log-20030211.142821.jar
    commons-jelly-tags-jsl-20030211.143151.jar.md5
(Continue reading)

Permalink | Reply | 1 comment |

Gmane