`@sentry/node` slows server start times significantly

[nathan-knight]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/nextjs

SDK Version

8.50.0

Framework Version

NestJS 10.4.2

Link to Sentry event

No response

Reproduction Example/SDK Setup

Sentry.init({
  dsn: '-',
  environment: process.env.ENV,
  enabled: !isLocal,

  integrations: [
    nodeProfilingIntegration(),
    Sentry.httpIntegration({
      breadcrumbs: true,
      ignoreOutgoingRequests: (urlPath) => {
        // Ignore requests to the Datadog agent
        return urlPath.startsWith('http://127.0.0.1:8126');
      },
    }),
  ],
});

Steps to Reproduce

Our API start times have been very slow with the vast majority of time being spent loading modules. I dug into the root cause by making Sentry run locally and profiling the launch of our app.

Hook._require.Module.require within require-in-the-middle which is used by @opentelemetry/instrumentation which is used by @sentry/node is responsible for a substantial amount of the launch time.

require-in-the-middle uses a package called resolve to determine if an import is the main module file or an internal one which is very slow, partially because it uses JSON.parse on each package.json for every file in that package that is imported (potentially multiple times). Is there anything the Sentry team can do to try to alleviate this issue for all of their customers? In my application I have patched require-in-the-middle to use Node internals (based on what DataDog does: https://github.com/DataDog/dd-trace-js/blob/6523d941297a8a08c8dcca91ab9fc202b26278b4/packages/dd-trace/src/ritm.js#L127) to resolve the correct file instead which cut our initial load time by 31%.

#14388 is probably related.

Expected Result

Start times to not be substantially affected by Sentry

Actual Result

Start times take substantially longer with Sentry

[mydea]

Hey, thanks for writing in. We'll see if we can make improvements to this upstream in require-in-the-middle - there will always be some overhead there but ideally we can find ways to cut this down as much as possible!

[timfish]

I've had a go at reproducing this and have seen more like 6-10% overhead rather than 30% reported but that's no doubt due to my benchmarks being more synthetic than a a proper full app startup.

There's an old open issue at require-in-the-middle to replace resolve which would probably be a good start:

• refactor: use core Node.js resolve function if possible nodejs/require-in-the-middle#25

[timfish]

The older PR does not pass the tests on all supported Node versions so I've created a PR that does:

• refactor: use core Node.js resolve function if possible nodejs/require-in-the-middle#96

If the minimum supported Node version of require-in-the-middle is bumped slightly, we can remove the need for resolve entirely.

[timfish]

require-in-the-middle v7.5.0 has been released which no longer uses resolve on newer Node.js versions.

There's a planned v8.0.0 release which will bump the minimum supported Node version slightly and remove resolve entirely.

[timfish]

@nathan-knight can this isue be closed now?

[nathan-knight]

@nathan-knight can this isue be closed now?

Yes, thank you for the help!