jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sridhar Raman" <sridhar.ra...@gmail.com>
Subject Re: Performance of save operation dependent on size of parent node?
Date Thu, 09 Oct 2008 06:19:04 GMT
My persistence manager is bundle.DerbyPersistenceManager.
The node that is getting versioned would typically have around 20
properties, out of which 12 or so woule be multi-value.

I shall attach the test-case soon.

On Wed, Oct 8, 2008 at 6:32 PM, Stefan Guggisberg <stefan.guggisberg@day.com
> wrote:

> On Mon, Oct 6, 2008 at 11:31 AM, Sridhar Raman <sridhar.raman@gmail.com>
> wrote:
> > I have a parent node which, initially, has 0 children nodes.  Now I add
> 1000
> > nodes, and perform a save.  I keep repeating this task.  Should the
> > performance of parent_node.save() deteriorate as the size of the parent
> node
> > increases?  That's what I am observing, despite the fact that the
> absolute
> > count of the number of nodes being saved is the same each time - 1000.
>  Is
> > this expected behaviour?
> >
> > Also, if the node that is getting saved is versionable, then the
> performance
> > deterioration is much worse.
> >
> > Some rough numbers-
> > Without versioning:
> > 1000 takes 10 seconds
> > 3000 takes 13 seconds
> > ...
> > 10000 takes 20 seconds
> > ...
> > 20000 takes 21 seconds
> >
> > With versioning:
> > 1000 takes 24 seconds
> > 3000 takes 26 seconds
> > ...
> > 10000 takes 40 seconds
> > ...
> > 20000 takes 118 seconds
> >
> > I can still live with the numbers that occur with no versioning.  But,
> with
> > versioning, it could be a problem.
>
> versioning does come at a price, i.e. it significantly impacts performance.
>
> however, your figures seem way to slow. please provide details about your
> configuration (repository.xml, deployment model) and ideally a simple,
> self-contained test case. i'd be happy to further investigate your problem.
>
> cheers
> stefan
>
> >
> > Thanks,
> > Sridhar
> >
>

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