jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Neale" <michael.ne...@gmail.com>
Subject Re: possible performance problem (need a way to test it)
Date Mon, 18 Sep 2006 15:59:17 GMT
It was suggested to me to open and close a session with each user request -
from my profiling - opening a session (other then first one) takes 1ms or
less - so its certainly feasable (but not sure about your case Alex !).

Its good to push at the boundaries like this, makes a better product and
more confidence for all - good luck !

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
> -----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
> ______________________________________________________________________

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