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 <[email protected]> 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 < > > [email protected]> 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. > > > > > > > >
