[undertow-dev] InMemorySessionManager.java performance

[Andrew Schmidt]

It appears to be this changeset that caused the performance degradation:

https://github.com/undertow-io/undertow/commit/636590a011ad8497286ef01f19dc9551a16eef79



> -----Original Message-----
> From: undertow-dev-bounces at lists.jboss.org [mailto:undertow-dev-
> bounces at lists.jboss.org] On Behalf Of Andrew Schmidt
> Sent: September-04-2014 10:59 AM
> To: undertow-dev at lists.jboss.org
> Subject: [undertow-dev] InMemorySessionManager.java performance
> 
> 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