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.
