[undertow-dev] InMemorySessionManager.java performance

[Stuart Douglas]

This seems really odd. This should only be re-scheduled if the condition 
newExpireTime < expireTime is true, which should only happen if the max 
inactive interval has been decreased. I have tested this out locally and 
it seems to be working as expected (i.e. only one executeAfter call).

Do you have a simple way to reproduce this?

Stuart

Andrew Schmidt wrote:
> My company is currently switching from jboss 4 =>  wildfly 8.1,   jsf + hibernate + richfaces.  (We develop on Windows)
>
> After profiling our application, I've found some major performance penalties in the InMemorySessionManager.java in undertow.   Specifically in the bumpTimeout() that gets called on every getAttribute call.  Each of these calls takes 15 ms, which  when called 100 times during the course of a jsf request,  adds up.  (The 15 ms occurs when the execute.executeAfter in netty tries to wake up another thread)
>
> Looking over the code:
> io/undertow/server/session/InMemorySessionManager.java
>
> -- snip
> synchronized void bumpTimeout() {
>              final int maxInactiveInterval = getMaxInactiveInterval();
>              if (maxInactiveInterval>  0) {
>                  long newExpireTime = System.currentTimeMillis() + (maxInactiveInterval * 1000);
>                  if(timerCancelKey != null&&  (newExpireTime<  expireTime)) {
>                      // We have to re-schedule as the new maxInactiveInterval is lower than the old one
>                      if (!timerCancelKey.remove()) {
>                          return;
>                      }
>                      timerCancelKey = null;
>                  }
>                  expireTime = newExpireTime;
>                  if(timerCancelKey == null) {
>                      //+1 second, to make sure that the time has actually expired
>                      //we don't re-schedule every time, as it is expensive
>                      //instead when it expires we check if the timeout has been bumped, and if so we re-schedule
>                      timerCancelKey = executor.executeAfter(cancelTask, maxInactiveInterval + 1, TimeUnit.SECONDS);
> -- snip
>
> If the time changes by 1ms,  then the expiration task is cancelled and a new one is scheduled.    But this new scheduling takes 15ms.  Therefore every call to getAttribute (which in turn calls bumpTimeout) will constantly cancel and reschedule the expiration tasks.    This seems heavy handed.    Also the comment seems to imply that the developer who wrote this was aware that rescheduling is expensive, yet it happens on every call.
>
> Disabling session expiration causes our application to run twice as fast.  (5.5 second page load goes down to 2.5)
>
>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev