There should be a way to disable OpenCensus stats and tracing

Currently, out-of-the-box client and server config includes a very expensive “no-op” in the form of the enabled-by-default opencensus tracing and stats interceptors. This is the case even if no implementation library is on the classpath, and disabling them is difficult/discouraged/impossible (without reflection) depending on the transport.

Benchmark                         (direct)  (statsAndTracing)  (transport)  Mode  Cnt      Score      Error  Units
TransportBenchmark.unaryCall1024      true               true    INPROCESS  avgt   10   3313.595 ±  107.360  ns/op
TransportBenchmark.unaryCall1024      true              false    INPROCESS  avgt   10   2142.610 ±   99.678  ns/op
TransportBenchmark.unaryCall1024      true               true  NETTY_LOCAL  avgt   10  64780.414 ± 1564.422  ns/op
TransportBenchmark.unaryCall1024      true              false  NETTY_LOCAL  avgt   10  60969.867 ± 1447.113  ns/op
TransportBenchmark.unaryCall1024      true               true        NETTY  avgt   10  85561.145 ± 3765.635  ns/op
TransportBenchmark.unaryCall1024      true              false        NETTY  avgt   10  81556.086 ± 2136.174  ns/op
TransportBenchmark.unaryCall1024      true               true  NETTY_EPOLL  avgt   10  79758.331 ± 3005.046  ns/op
TransportBenchmark.unaryCall1024      true              false  NETTY_EPOLL  avgt   10  75667.486 ± 2734.508  ns/op
TransportBenchmark.unaryCall1024      true               true       OKHTTP  avgt   10  74714.350 ± 2848.833  ns/op
TransportBenchmark.unaryCall1024      true              false       OKHTTP  avgt   10  70527.535 ± 2945.292  ns/op

There’s also significantly more garbage produced when enabled.

It would be great to enable these only when the impl library is detected, however:

• There are circumstances when it might be there but not used
• It may be the case that only one of stats or tracing is being used
• Even if it is being used, instrumentation overhead of this magnitude may be considered undesirable (and these numbers are just the api plumbing without any additional cost from the impl itself)

Could these be changed to be disabled by default? I’m unsure why such settings are considered internal when they pertain to external functionality. There’s not much danger of anyone “accidentally” leaving it disabled since it would be immediately apparent that the stats aren’t working but the converse is of course true and I would assume most common.

[zhangkun83]

As we revisit the decision to include the OpenCensus into grpc-core, we regret it. That’s why we don’t expose public API to disable it. We are considering moving that of grpc-core and make its own artifact grpc-census. There may be two ways to approach it:

1. Let the core find classes of grpc-census and load then if available. The user controls whether to have stats/tracing by having or not having grpc-census in their class path.
2. Ditch dynamic loading, and have a utility class in grpc-census to install interceptors/tracers on the channel/server builders.

Option 1 allows current stats/tracing-dependent users to migrate without any code change. Option 2 is cleaner as it gives the user the maximum control, while it requires code changes to migrate. I personally prefer Option 2 but I am not sure whether the churn brought to users is acceptable. @ejona86 may want to chime in.

[ejona86]

Yes, I think #6577 (not #5510 😄) addressed this. I don’t think all the discussions are done, but the major issue should be addressed now.

Closing. @njhill, if things still don’t look right we can reopen.