12:27 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev