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