[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