[java-identity-provider COMMIT] in /trunk: idp-authn-api/pom.xml idp-authn-api/src/main/java/net/shibboleth/idp/authn...

[Cantor, Scott]

> I don't understand the logger lookup overhead right now, but that
> seems like something that could be minimized, especially if the
> logging service is being queried, again I haven't read the code...

In Metrics proper, there's a registry (map) of all the metric objects, so accessing a metric is always a map lookup. Unless we statically fetch the metric into a static class member, our prototype beans are all going to pay that lookup price every time they record something.

The logger overhead is if we implement a conditional wrapper around that lookup to check the level of a logging category derived from the metric's name. So instead of a map lookup, we're doing additional string manipulation, running a LoggerFactory.getLogger() call and a level check. I made it even "worse" by supporting a map of metric names to log levels, so that you could attach a level to require for a given metric (some DEBUG, some INFO, etc.)

So all of that code is overhead. For the counters I just checked in, I think it's pretty questionable (that's an understatement). For the Timers, it's clearly not unjustified. For really expensive metrics, it would obviously pay off a lot.

Of course, we could improve things somewhat by implementing an API for both conditional and unconditional Metric access, with the latter bypassing the on/off controls.

-- Scott