jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Working with JCR in highly concurrent applications
Date Wed, 20 Sep 2006 19:56:24 GMT
Hi,

On 9/20/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
> On 9/20/06, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> > On 9/20/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
> > > But my question is: why is this happening (and why would it be normal)?
> >
> > What are you referring to, the ItemNotFoundException?
>
> No, to the performance penalty. I mean, if you have a couple of
> concurrent accesses to a RDBMS you will hardly notice that. Or am I
> doing a wrong comparison?

Ah, you mean the linear increase in the wall clock time? That's very
much expected when you have concurrently executing threads and has
nothing to do with the Jackrabbit implementation. For example, if you
have a computation that takes a minute to execute and requires no
access to shared resources, then if you add a second thread doing the
same computation, you'd expect both threads to take about two minutes
to execute if the scheduling is fair.

Another possible measure is of course count the total number of
property reads within a given timeframe given any number of concurrent
threads. That number should go up when the first few threads threads
are added since the I/O waits can be used to process other threads,
but then start slowly declining due to the context switching and other
thread overhead. I'll actually run a test like that, stay tuned for
the results...

BR,

Jukka Zitting

-- 
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development

Mime
View raw message