[undertow-dev] InMemorySessionManager.java performance

[Andrew Schmidt]

Well on windows,  scheduling a new task takes more than 1 ms.   Therefore every call 
to bumptimeout cause the next bumpTimeout to reschedule.  
(Since the ''if(newExpireTime < expireTime)''    is comparing ms)

I'm going to test this out on linux and determine if if the same problem exists.   Are you 
testing on linux ?

But even still, over the course of a jsf request, which takes anywhere from 100ms to 
1second,  there could be upwards of  100 getAttribute calls which would be on 
different ms's.  And that means 100+ cancel's / reschedule's .

 
> -----Original Message-----
> From: Stuart Douglas [mailto:sdouglas at redhat.com]
> Sent: September-04-2014 11:27 PM
> To: Andrew Schmidt
> Cc: undertow-dev at lists.jboss.org
> Subject: Re: [undertow-dev] InMemorySessionManager.java performance
> 
> 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