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 Mon, 30 May 2016 19:00:21 GMT
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