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: possible performance problem (need a way to test it)
Date Mon, 18 Sep 2006 15:58:35 GMT
On 9/18/06, Miro Walker <miro.walker@cognifide.com> wrote:
> Hi Alex,
> I think the investigation is a good idea, but the way we sidestepped any
> issues like this was to have our application maintain a pool of sessions
> that are shared out between user threads. This works for us as we are
> handling user locking and security in the application tier - I guess it
> depends on your overall architecture, but it might be worth considering
> if you're planning very high concurrency.
> miro

Thanks for the idea Miro. I was thinking about this in the past, but
as I pointed out not the session creation is the problem but the query
execution. So, I am not sure how this would help me. Also, from
previous discussions my understanding is that Session creation should
be a quite simple/chiep operation (maybe a good comparison would be
with a Hibernate Session).

.w( the_mindstorm )p.

> -----Original Message-----
> From: Alexandru Popescu [mailto:the.mindstorm.mailinglist@gmail.com]
> Sent: 18 September 2006 16:18
> To: userJackrabbit
> Subject: possible performance problem (need a way to test it)
> Hi!
> I have identified a possible performance problem with high concurrency
> querying against JCR. Still, I would like to have an easy way to
> reproduce it, so that I can profile it. I am wondering if there are in
> the Jackrabbit source base good samples on how to set up a quick
> testing repository.
> This was the first part. Now about the real problem I am seeing: when
> accessing the JCR repo from multiple concurrent threads (each using
> its own Session) and we perform querying we see a huge CPU load and
> the response times are growing very fast:
> - for 5 concurrent threads the query reponse times are around 200-500
> ms; server load about 0.65-0.7
> - for 100 concurrent threads the query response times are around
> 150000-200000 ms; server load about 7-7.5
> As you can see these are very dangerous numbers, and I would
> definitely like to figure out what is the problem behind them, because
> in my application I can expect something around 300 concurrent threads
> access.
> I know I can start looking at different options like caching and
> similar ideas, but firstly understanding the real problem will help me
> a lot.
> Many thanks for any helping ideas and comments,
> ./alex
> --
> :Architect of InfoQ.com:
>  .w( the_mindstorm )p.
> Co-founder of InfoQ.com
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

View raw message