isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From César Camilo Lugo Marcos <cesar.l...@sisorg.com.mx>
Subject Re: Concurrency
Date Tue, 31 May 2016 14:12:30 GMT
Thank you both for the hint. I am looking into JProfiler. Still,
anything about the concurrency control options?

Cesar.

On Tue, 2016-05-31 at 11:13 +0200, Jeroen van der Wal wrote:
> I agree with Martin that profiling is the only way to go. To illustrate: we
> recently made some code 8 times faster by a few simple code changes on
> bottlenecks revealed by JProfiler. And those were in places that we've
> never guessed.
> 
> On 31 May 2016 at 08:39, Martin Grigorov <mgrigorov@apache.org> wrote:
> 
> > Hi,
> >
> > To find out where is the problem you will have to use a profiler like
> > JProfiler, Yourkit, JVisualVM, etc.
> > Even some thread dumps would help to see what is going on.
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Mon, May 30, 2016 at 9:00 PM, César Camilo Lugo Marcos <
> > cesar.lugo@sisorg.com.mx> wrote:
> >
> > > Hello,
> > >
> > > I would like to add to this topic the following:
> > >
> > > Most of the transactions we are testing in these stress tests are not
> > > bound in ACTIONS, but just plain reads or default transactions using
> > > Apache ISIS wicket viewer defaults. I don't see any place where I could
> > > define semantics for default read or write transactions not bound into
> > > ACTION methods. Is there any place I should look into for that?
> > >
> > > Cesar.
> > >
> > >
> > > On Mon, 2016-05-30 at 18:45 +0000, César Camilo Lugo Marcos wrote:
> > > > Hello,
> > > >
> > > > We have sarted performing some stress tests to our Apache ISIS
> > > > application. We have found this behavior:
> > > >
> > > > - If we run 1 concurrent user, average response times to the main
> > object
> > > > reads through the wicket viewer are from 1 to 1.5 seconds.
> > > > - If we run 2 concurrent users, same transactions go to average
> > response
> > > > times up to 16 to 27 seconds.
> > > > - If we run 10 concurrent users, the transactions start to slow down
> > > > significantly until the app server freezes and we have to restart it.
> > > >
> > > > As you can see, this is a very significant increase in response time
> > for
> > > > such a slight change in user load (from 1 user to 2 users). So we are
> > > > guessing we should look into the concurrency control.
> > > >
> > > > In the documentation I have found that the only way to influence the
> > way
> > > > Apache ISIS manages transactions and concurrency checking is by using
> > > > the semantics configuration of the ACTION annotation.
> > > >
> > > > semantics=SAFE_AND_REQUEST_CACHEABLE
> > > > semantics=SAFE
> > > > semantics=IDEMPOTENT
> > > > semantics=IDEMPOTENT_ARE_YOU_SURE
> > > > semantics=NON_IDEMPOTENT
> > > > semantics=NON_IDEMPOTENT_ARE_YOU_SURE
> > > >
> > > > I just wanted to confirm if this is the place to look into, or are
> > there
> > > > any other places where we should be looking into too, to solve the
> > > > performance issue.
> > > >
> > > > Cesar.
> > >
> > >
> >

Mime
View raw message