[undertow-dev] Date Handler time (optimisation)

[Bernd Eckenfels]

Hello,

in Undertow 1.0.1 the DateHandler retrieves System.nanoTime() on each
request and compares it against a deadline to decide if it should also
query wallclock (via System.currentTimeMillis).

I see two possible optimizations here:

If the "Record request start time" option is set, the nanos value
can be read from the exchange.getRequestStartTime and does not need
another query. (Alternatively you can switch the record option off
and make DateHandler write to exchange.setRequestStartTime() to make
the syscall count: the additional time is
available without specifying the RECORD option).


The alternative optimization is about not using the nanos clock for
determining if cached value is stale but directly requesting the
wallclock millis. For one, I think the latency of nanoTime is not much
better (on some systems worse) than System.currentTime (after all, it
is an hotspot intrinsic) and every second both clocks would be asked
(multiple times its a race).

When having the current millis value, you could also check
if actually the next second has started (and avoid the rouding problem
with "nanos + 1000000000".

(And again, if the wallclock time is determined this way, it would make
sense to add it as a field on exchange?)


The code+cache is BTW in two places:

io.undertow.util.DateUtils.addDateHeaderIfRequired(HttpServerExchange)
io.undertow.server.handlers.DateHandler.handleRequest(HttpServerExchange)

BTW: I think the documentation should mention this. Here are some
things which should be included (somewhere):

"If you do not add the DateHandler Undertow might still add a Date:
header if response does not have one and the ALWAYS_SET_DATE
Header option is TRUE or missing. Using "ALWAYS_SET_DATE" is prefered,
as it will use the latest possible time before the response entity is
generated. The name of the option might be missleading, it does not
ansure the header is always overwritten, it only ensures there is one
set if there was not produced by the handlers."


Once the above options are discussed and decided I can provide patches
for the various doc locations.

Bernd

PS: I participated in an experiment* from Aleksey (of JMH fame) and had
a few strange results where currentTime had high latency, on the
other hand there are cases where nanoTime has high latency as
well (see 
http://shipilev.net/blog/2014/nanotrusting-nanotime/). I think overall
typical numbers show comparable latencies for both (<20ns). I asked
him, if he can share his experiences.

* https://github.com/shipilev/timers-bench