[undertow-dev] InMemorySessionManager.java performance

Stuart Douglas sdouglas at redhat.com
Fri Sep 5 17:08:35 EDT 2014



Andrew Schmidt wrote:
> 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)

newExpireTime and expireTime are both calculated before the task is 
scheduled, so it should not matter how long the scheduling takes. I 
still can't see the problem with the logic. System.currentTimeMillis() 
should always increase or stay the same, so newExpireTime should always 
be larger than or equal to expireTime.

Stuart

>
> 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


More information about the undertow-dev mailing list