Re: [undertow-dev] InMemorySessionManager.java performance

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)

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@redhat.com] > Sent: September-04-2014 11:27 PM > To: Andrew Schmidt > Cc: undertow-dev(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev