otlpreceiver: performance issue about otlpreceiver invoke proto.Size slow path

[hanjm]

Describe the bug
The otlpreceiver consume lots of cpu for proto.Size, marshal to buffer, get buffer size.
Here is the pprof:



Code:

opentelemetry-collector/config/configgrpc/configgrpc.go

Lines 266 to 267 in f2a0133

	// Enable OpenTelemetry observability plugin.
	opts = append(opts, grpc.WithUnaryInterceptor(otelgrpc.UnaryClientInterceptor(otelOpts...)))

Steps to reproduce
Run collector with otlp receiver.

What did you expect to see?
Use fast path to get size of proto message.
What did you see instead?
slow path to get size of proto message, marshal to buffer, get buffer size.

What version did you use?
v0.59.0

What config did you use?

Environment
OS: Linux
Compiler: Go 1.19

Additional context

[gbbr]

Hi Jimmie!

I'm not sure familiar with this code, but maybe I can help? What is the fast path that you were thinking of? How should it work instead?

Also, is this the right repository for this issue? It seems like the problematic code lives in open-telemetry/opentelemetry-go, and the problematic call lives in golang/protobuf.

[hanjm]

hi @gbbr , thank your reply.

What is the fast path that you were thinking of? How should it work instead?

I think it shoud try get size from asserting interface Size() int, then try to use proto.Size

is this the right repository for this issue?

opentelemetry-collector use gogoprotobuf, but opentelemetry-go-contrib use golang/profobuf. it happens in otlpreceiver, so i create issue in this repository, I have open a issue to opentelemetry-go-contrib repository just now.

[gbbr]

I think it shoud try get size from asserting interface Size() int, then try to use proto.Size

Thanks for clarifying. I think that makes sense. I would update the "What did you expect to see?" in the Description of the issue to say that.

[atoulme]

Is this fixed with open-telemetry/opentelemetry-go-contrib#3168?

[hanjm]

fixed. close it .