-----Original Message-----
From: undertow-dev-bounces(a)lists.jboss.org [mailto:undertow-dev-
bounces(a)lists.jboss.org] On Behalf Of Andrew Schmidt
Sent: September-04-2014 10:59 AM
To: undertow-dev(a)lists.jboss.org
Subject: [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)
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev