[undertow-dev] Date Handler time (optimisation)

[Stuart Douglas]

DateHandler is deprecated, it is only still present so old code that 
uses it will not fail, it will be removed at some point in the future.

I have changed the way that DateUtils works to register a timer to 
invalidate the date string, so now in most cases no system call will be 
required.

Stuart

Bernd Eckenfels wrote:
> 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
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev