Slowdown with v2

[andersekdahl]

Hi!
I just upgraded from latest v1 to latest v2 of @splunk/otel and our Node server now takes 5-10 seconds to start. Haven't looked deeply into what takes time but this is my code:

import { start } from '@splunk/otel';
start({
  serviceName: 'my-service',
});

If I remove the call to start() the server starts quickly again. Any idea what could cause it? Anything I can do? I have these packages installed as well:

@opentelemetry/instrumentation-express: 0.31.2
@opentelemetry/instrumentation-http: 0.34.0
@opentelemetry/instrumentation-redis: 0.33.0

[seemk]

Hi, what's the exact version you're using - 2.1.0?

In 2.0.0 we made the change to bundle instrumentations and in a release candidate version we were using a version of OTel that had a known problem related to startup times.

However the latest version of Splunk OTel should be using the fixed OTel versions.

[seemk]

And a small side note: with v2 it is no longer necessary to install instrumentation packages yourself, unless of course you want to use something not in the default instrumentations list.

[andersekdahl]

Ah, then that's perhaps the issue. I have a colleague who reported the same slowdown but he instead uninstalled the explicit otel packages and said that it fixed the issue. So I'll uninstall them and see if that works for me as well. Thanks for the quick reply!

[andersekdahl]

Looks like the @opentelemetry packages are peer dependencies, which means I still need to install the ones I want?

[seemk]

The OpenTelemetry instrumentation packages don't need to be installed one by one any longer. At the moment the only peer dependency is @opentelemetry/api: https://github.com/signalfx/splunk-otel-js/blob/main/package.json#L152

The API package is a peer dependency to avoid users installing old API packages alongside the instrumentations - which can cause detached spans in traces, but it is not mandatory to install it.

[seemk]

@andersekdahl Were the problems you had resolved?

[seemk]

Closing this as it should be resolved now with the newer @opentelemetry/instrumentation packages.