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 16:06:20 GMT
you mentioned 100 concurrent threads == 100 concurrent sessions. I was
making the assumption (probably wrong ;) that you were doing a web app - and
that the query bottleneck was to do with the number of *open* sessions, if
its not, then I don't think open/close a session would help (just thought it
may, as in a web app its unlikely that you really get all the requests at
the same time, and if you do sometimes you can throttle them before they
even get to the app).

Yeah the hibernate session analogy was what I was told, and it seems to hold
true from my experiments.

Enjoy !



On 9/18/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
>
> 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).
>
> ./alex
> --
> .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
> > ______________________________________________________________________
> >
>

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