jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu" <the.mindstorm.mailingl...@gmail.com>
Subject Re: Working with JCR in highly concurrent applications
Date Wed, 20 Sep 2006 13:52:26 GMT
On 9/20/06, Marcel May <marcel.may@consol.de> wrote:
> I'm not sure, but Jackrabbit with a DB backend uses exactly one DB
> connection (where all access going to the DB must be serialized over,
> since JDBC connections can not be used concurrently) . So, if you're
> using parallel access with lots of threads, all JCR access which
> requires DB access gets more or less serialized.
>

I initially thought quite the same, but it looks like the
PersistenceManager work is not so expensive. For example:

1/
NodeImpl.getProperty 31200calls 75343ms => PersistenceManager.load
312calls 609 ms

2/
NodeImpl.getProperty 90800calls 85140ms => PersistenceManager.load
104calls 234ms

Maybe these are not the exact points, but I couldn't identify any
point where the PersistenceManager would be the guilty one.

./alex
--
.w( the_mindstorm )p.

> I think the JCA adapter does pool Jackrabbit instances, each with an own
> DB connection. Using the JCA Jackrabbit adapter should avoid this
> problem ... maybe. Or use a FS backend instead of a DB....
>
> Could this be an explanation for Alex's experience?
> Can somebody confirm or comment this?
>
> Cheers,
> Marcel
>
> Alexandru Popescu wrote:
> > Hi everybody!
> >
> > First of all I must say that I do not intend to create noise about
> > this, but unfortunately it looks like I have reached a dead end.
> > Hopefully there is something I am doing wrong, or that I am supposed
> > to do differently. I haven't found any best practices or
> > recommendations anywhere, so this is a try-and-fail process (and I am
> > saying it is a "fail" because till now I haven't figured out the
> > correct way to do it).
> >
> > Scenario: access a set of nodes (matching more or less complex
> > filtering criteria) from a highly concurrent application.
> >
> > As you can see this is a pretty straight forward scenario.
> >
> > I have tried 2 different approaches and unfortunately both are
> > degrading when used in this concurrent environment. And I am not
> > talking about a few hundred concurrent threads: I have tested it with
> > 50, respectively 100 concurrent threads.
> >
> > The common usage scenario is having a JCR Session per thread association.
> >
> > Usage scenario 1:  Query API.
> >
> > As posted in a previous email this is degrading very fast. See email:
> > "possible performance problem (need a way to test it)" from Sept 19th.
> >
> > Usage scenario 2: Normal navigation API
> >
> > The second approach was to manually navigate the parent child nodes,
> > read just a couple of properties in the first place so that I do
> > manually the filtering, and only afterwards fetch the entire node
> > properties.
> >
> > Once again, the performance is going down 2-3 order of magnitude (from
> > hundreds of ms down to ten thousands (even hundred thousand) ms).
> >
> > I have profiled the 2nd test and at the first glance the most
> > expensive operations are the following calls:
> >
> > ItemManager.createItemInstance
> > ItemManager.retrieveItem
> >
> > These calls are always invoked from Node.getProperty,
> > Node.hasProperty, etc., so I don't think I am doing something wrong.
> >
> > I am extremely worried about these results because I don't see a way
> > to achieve my scenario without involving more advance techniques. I
> > agree that if my application needs good performance these techniques
> > will need to be used, but I find it very concerning the fact that
> > performance is degrading so fast by its own.
> >
> > I would be happy to hear any comments, any suggestions, any pointers
> > to what I am doing wrongly, that will lead me to a good solution.
> >
> > Many thanks in advance,
> >
> > ./alex
> > --
> > :Architect of InfoQ.com:
> > .w( the_mindstorm )p.
> > Co-founder of InfoQ.com
>
>
> --
> Marcel May
> ConSol* Software GmbH
> Tel: +49 89 45841-155
>
>

Mime
View raw message