9:55 a.m.
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